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BRIEF 


Requirement 

The  improved  capabilities  of  new  weapons  systems  to  be  intro¬ 
duced  into  the  Army  inventory  over  the  next  30  years  are  expected 
to  cause  related  increases  in  the  complexity  of  materiel  systems. 
Current  systems  regularly  exceed  the  capabilities  of  the  personnel 
available  to  operate  and  maintain  the  systems,  due  to  unnecessary 
system  complexity.  Also,  the  number  and  qualifications  of  personnel 
who  will  compose  the  future  Army  are  expected  to  continue  to  be 
limited  due  to  legislative  and  demographic  trends  which  will  continue 
into  the  future.  If  these  two  parallel  trends  continue,  a  crisis 
situation  where  the  Army  possesses  highly  capable  materiel  systems 
but  lacks  personnel  with  the  capabilities  needed  to  maintain  and 
operate  the  systems  is  likely. 

Since  the  trend  toward  fewer,  potentially  less  capable  personnel 
is  unlikely  to  change  in  the  foreseeable  future,  attention  must  be 
directed  toward  the  characteristics  of  materiel  systems  which  make 
the  systems  "complex"  (i.e.,  difficult  to  operate  and  maintain). 

One  major  reason  why  materiel  systems  are  "complex"  is  that  little 
attention  is  given  to  the  capabilities  and  limitations  of  potential 
system  operators  and  maintainers  during  system  design.  This  lack 
of  attention  is  due  to  a  number  of  factors,  one  of  the  most  important 
of  which  is  a  general  lack  of  knowledge,  on  the  part  of  engineers 
who  design  materiel  systems,  of  tools  and  techniques  which  can 
be  used  in  the  materiel  system  design  process  to  evaluate  and 
control  the  impacts  of  designs  upon  manpower  and  personnel  require¬ 
ments  and  training  (MPT).  In  turn,  a  major  cause  of  designer 
lack  of  knowledge  of  human  factors  assessment  and  design  techniques 
and  principles  is  that  human  factors  principles  and  techniques 
are  not  provided  in  a  language  with  which  the  design  engineer  is 
familiar.  Thus,  there  is  a  need  for  a  "common  language"  by  which 
the  government  can  communicate  its  requirements  and  desires  about 
the  MPT  characteristics  of  evolving  materiel  systems  to  materiel 
system  designers  and  verify  that  the  requirements  are  understood, 
complied  with,  and  are  effective  in  controlling  the  MPT  impacts 
of  systems  design. 

This  leading  effort  was  conceived  to  deal  with  three  basic, 
first-order  issues  leading  to  the  development  of  such  a  "common 
language . "  These  were : 

Identify  the  critical  decisions  made  in  the  materiel 
system  acquisition  process  which  have  the  most  impact 
on  the  MPT  characteristics  of  systems ,  where  in  the 
acquisition  process  these  decisions  are  made,  and  who 
has  responsibility  for  the  decisions; 


v 


.  Identify  the  most  effective  means  of  communicating 

"critical"  MPT  decisions  to  designers  so  that  the  decisions 
and  associated  technologies  and  data  are  effectively 
utilized  by  the  designers  to  control  the  MPT  impacts  of 
system  designs; 

.  Determine  means  of  verifying  that  system  designers  under¬ 
stand  the  nature  and  importance  of  MPT  decisions,  utilize 
those  decisions  and  related  technologies  to  influence 
materiel  system  design,  and  that  the  decisions  and  their 
utilization  have  desired  ultimate  impacts  on  the  MPT 
characteristics  of  fielded  systems. 


Procedure 

A  detailed  examination  of  the  materiel  system  acquisition  process 
was  made  through  study  of  selected  reports  and  documents,  to  identify 
candidate  "critical"  MPT  decisions  made  in  the  acquisition  process. 

From  the  candidate  "critical"  decisions,  a  panel  of  highly  experienced 
personnel  selected  the  decisions  to  be  considered  those  with  the  most 
impact  upon  materiel  system  MPT  factors.  The  same  panel  studied  the 
issues  of  communicating  the  decisions  to  desiqners  and  verifying  the 
understanding,  utilization,  and  impact  of  the  decisions  and  associated 
relevant  information,  and  arrived  at  first  approximations  to  attributes 
of  a  "common  language"  and  verification  procedures.  The  conclusions 
and  findings  of  the  panel  were  subsequently  refined  and  developed  into 
a  set  of  preliminary  characteristics  or  attributes  of  the  desired 
"common  language." 


Findings 

A  small  set  of  extremely  topic-specific  MPT-impacting  decisions 
which  can  be  made  early  in  the  system  acquisition  process  and  thus  be 
communicated  to  designers  from  the  very  outset  of  their  involvement  in 
system  design  were  identified.  These  decisions,  or  system  MPT 
characteristics,  are  in  two  broad  areas:  (1)  decisions  which  specify 
allowable  or  permissible  characteristics  of  MPT  factors  of  systems  to 
be  developed;  and  (2)  decisions  which  specify  characteristics  of  the 
materiel  systems  to  be  designed  which  have  profound  influence  on  the 
MPT  characteristics  of  the  ultimate  personnel /materiel  system. 

It  was  next  determined  that  communication  of  the  "critical" 
decisions  identified  must  take  place  in  the  form  of  firm  constraints 
upon  the  MPT  characteristics  of  the  total  personnel /materiel  system  to 
be  designed.  These  constraints  should  be  a  major  part  of  the  system 
performance  specification,  on  a  coordinate  level  with  materiel 
performance  requirements.  The  constraints  provided  for  a  particular 
system  should  have  the  following  additional  attributes: 


.  Deal  with  specifically  defined  system  MPT  characteristics  or 
materiel  system  characteristics  with  major  MPT  impact. 

.  Rationale  and  justification  for  constraints  presented  to 
support  designers'  understanding  of  constraint  Impact  and 
importance. 

.  Constraints  stated  in  specific  quantitative  terms  to  provide 
understandabil ity  and  verification  of  compliance. 

.  Guidance  to  tools,  techniques,  and  data  to  assist  designers 
in  contraint  compliance  provided  (designer's  handbook). 

.  Effective  consequences  of  failure  to  meet  W>T  constraints 
incorporated  in  system  development  contractual  documents 
(MPT  factors  "warranties"). 

Finally,  the  issue  of  verification  of  designers'  understanding  of 
and  efforts  to  comply  with  constraints,  and  the  ultimate  impacts  of  the 
constraints  was  addressed.  Verification  of  designers'  comprehension  of 
the  nature,  impact,  and  importance  of  MPT-related  design  constraints  is 
proposed  to  take  place  through  evaluation  of  designers'  proposals  for 
system  development,  wherein  specific  initiatives  and  plans  to  deal 
explicitly  with  MPT  impacts  of  design  are  to  be  required.  Plans  and 
initiatives  to  meet  MPT  constraints  will  form  a  major  evaluation  factor 
in  selection  of  designers  in  the  system  acquisition  process.  Verifying 
that  designers  actually  consider  MPT  impacts  of  design  during  the  evol¬ 
ution  of  materiel  sytems  can  be  made  through  requiring  explicit  evalua¬ 
tion  and  documentation  of  MPT  factors  in  design  tradeoff  decisions  and 
periodic  review  of  the  MPT  implications  of  evolving  system  designs  by 
the  government.  Evaluating  the  ultimate  impact  of  imposing  MPT 
constraints  on  design  can  only  be  done  by  measuring  the  attained  MPT 
characteristics  of  fielded  systems,  and  comparing  the  attained  param¬ 
eters  with  the  constraints  placed  on  those  factors  prior  to  design. 

Two  major  issues  to  be  resolved  in  further  development  of  the 
"common  language"  communication  process  were  identified  in  this  work. 
The  first  is  a  need  to  study  and  rationalize  the  process  by  which 
initial  MPT  decisions  are  made  during  system  concept  formulation  phases 
of  system  acquisition  (before  the  designers'  involvement)  to  ensure 
that  information  which  is  needed  to  make  critical  MPT  decisions,  upon 
which  constraints  are  based,  is  developed  and  utilized.  The  second 
issue  is  a  need  for  an  integrated  "designer's  handbook"  which  presents 
principles,  techniques,  and  data  required  to  knowledgably  address  MPT 
Impacts  of  system  design  in  a  form  and  format  suitable  for  use  by  the 
working  design  engineer  and  engineering  manager. 


Utilization  of  Findings 


The  findings  of  this  work  represent  a  first  step  in  developing  a 
means  to  control  and  intelligently  constrain  the  MPT  impacts  of  new 
materiel  systems,  through  enhancing  the  process  of  communication  about 
critical  MPT  issues  between  the  government  and  materiel  system 
designers.  Considerable  refinement  of  the  basic,  first-approximation 
principles  derived  in  this  study  will  be  necessary  to  create  and 
implement  an  effective,  practical,  and  workable  system  for  controlling 
MPT  factors  of  designs.  The  next  step  in  the  evolution  of  a  "common 
language"  for  government -designer  communications  should  be  to 
explicitly  address  the  major  issues  identified  in  this  work. 


INTRODUCTION 


In  order  to  Improve  Its  effectiveness  In  accomplishing  the  overall 
defense  mission,  the  Army  will  add  a  large  number  of  new  and  innovative 
weapon  systems  to  its  inventory,  within  the  next  20-30  years.  Although 
these  systems  will  provide  new  and  improved  capabilities,  the  systems 
will  be  complex.  This  implies  that  more  capable  (and  perhaps  more 
numerous)  personnel  will  be  required  to  operate  and  maintain  the  new 
systems. 

Contrasted  to  requiremer.ts  for  an  Increased  number  of  personnel 
and  more  capable  personnel  to  support  new  systems  are  increasing 
limitations  on  the  size  of  the  Army  force  and  tighter  personnel 
budgets.  If  these  two  trends  continue,  there  will  come  a  point  when 
the  Army  has  on  hand  a  large  number  of  very  capable  weapons  systems 
based  on  the  latest  technologies,  but  no  one  capable  of  operating  and 
maintaining  them.  To  prevent  this  hypothetical  outcome,  one  or  the 
other  of  the  trends  involved  must  be  reversed.  It  is  unlikely  that  the 
Congress  will  see  fit  to  authorize  a  greatly  expanded  Army  personnel 
budget  to  the  extent  that  would  be  required  to  support  Ph.D.  PFCs; 
hence,  the  weapon  systems  of  the  future  will  have  to  be  designed  to  be 
operated  by  the  sorts  of  personnel  who  are  available.  The  operations 
and  maintenance  characteristics  of  the  systems  must  be  matched  to  the 
skills  and  knowledge  of  the  personnel  available. 


One  reason  that  today's  weapon  systems  are  "complex"  (i.e., 
difficult  to  operate  and  maintain)  Is  that  system  designers  have  had  a 
free  rein  to  apply  the  latest  technologies  to  create  Increasingly 
advanced  system  capabilities,  but  have  been  allowed  to  Ignore 
the  Implications  of  these  expanded  capabilities  In  terms  of  the  charac¬ 
teristics  of  the  personnel  who  operate  and  maintain  the  systems.  It 
has  been  well-established  over  decades  of  research  that  the  character¬ 
istics  of  materiel  systems  determine  the  required  characteristics  of 
system  operators  and  maintainers,  and  that  materiel  systems  should  be 
designed  with  the  capabilities  and  limitations  of  the  target  population 
In  mind.  A  vast  body  of  data  on  the  capabilities  and  limitations  of 
personnel  has  been  generated  by  human  factors  researchers,  operations 
researchers,  psychologists,  arid  systems  engineers.  Techniques  for 
determining  the  Implications  of  many  aspects  of  hardware  designs  upon 
personnel  performance  requirements  have  also  been  created  and 
validated.  Yet  these  data  and  techniques  remain  unused. 

There  are  several  possible  reasons  for  this  state  of  affairs: 

1.  The  designers  of  materiel  systems  may  not  be  aware  of  the 
existence  of  the  data  and  techniques. 

2.  Designers  may  be  aware  of  the  data  and  discount  the 
importance  of  the  data  to  their  efforts. 

3.  Designers  may  not  know  how  the  data  applies  to  what  they 
are  trying  to  do,  or  how  to  use  it. 

4.  The  designer  just  may  not  care. 

While  all  of  these  reasons  may  apply  to  some  extent  at  any  given  time. 
It  is  suspected  that  the  third  reason  (don't  know  how  the  data  applies 


or  how  to  use  it)  may  be  responsible  for  many  of  the  problems  that 
exist  today.  Since  designers  are  not  sure  how  or  why  data  (concerning 
the  ways  in  which  hardware  characteristics  affect  the  performance  of 
people)  apply  to  his  design  problem,  he  simply  ignores  the  data  and 
goes  on  designing  hardware.  The  ultimate  impacts  of  this  state  of 
affairs  are  not  hard  to  observe:  competition  by  the  various  armed 
services,  and  branches  within  the  services,  for  competent  personnel  vrfio 
are  desperately  needed  to  operate  and  maintain  needlessly  complex 
hardware  systems;  proliferation  of  NCOs  within  all  the  services; 
extended  equipment  downtime  because  nobody  knows  how  to  isolate  hard¬ 
ware  malfunctions— examples  are  legion. 

Since  one  possible  reason  for  the  failure  of  designers  to  incor¬ 
porate  data  and  techniques  which  can  minimize  manpower  and  training 
requirements  is  uncertainty  about  how  such  data  and  techniques  can  be 
integrated  into  their  design  process  (with  consequent  reluctance  to 
attempt  to  utilize  these  tools),  a  problem  of  communication  exists. 

One  reason  for  the  existence  of  this  communication  problem  is  that  data 
and  techniques  for  identifying  the  impacts  of  materiel  system  charac¬ 
teristics  on  manpower  and  training  needs  have,  in  large  part,  been 
created  in  professional  communities  other  than  those  associated  with 
engineering  design.  This  means,  practically,  that  a  different 
"1  anguage"— i  .e.,  professional  terminology  than  that  used  by 
engineers— has  been  used  in  describing  concepts,  data,  principles,  etc. 
which  link  hardware  design  factors  to  human  factors.  Thus,  the 
engineers  don't  understand  what  human  factors  people  are  talking  about, 
don't  understand  why  human  factors  is  important,  and  don't  understand 
how  to  use  human  factors  data.  This  is  not  always  the  case,  but  is 
probably  more  typical  than  not. 


Coupled  to  the  problem  of  different  professional  languages  may 
also  be  a  “not  invented  here"  syndrome  associated  with  particular 
engineering  design  organizations.  In  this  situation,  the  designer 
feels  that  he  is  the  "expert"  on  all  facets  of  design,  and  someone 
else's  solutions  "can't  possibly  work  in  our  approach."  In  any  case, 
one  factor  in  the  failure  of  designers  to  apply  appropriate  data  and 
technology  to  minimize  the  manpower  and  training  requirements  of  their 
designs  is  the  use  of  broadly  different  terminologies  by  human  factors 
people  (who  develop  those  technologies)  and  the  design  engineers  (who 
should  use  the  technologies);  i.e.,  lack  of  a  "common  language"  between 
the  two  communities.  The  effort  described  in  this  report  was  Initiated 
to  study  this  "common  language"  problem. 

The  purpose  of  the  present  study  has  been  to  address  three  global 
areas  dealing  with  the  problem  of  a  "common  language."  These  three 
areas  are: 

1.  Define  the  major  decisions  in  the  system  acquisition 
process  where  manpower,  personnel,  and  training  (MPT) 
characteristics  of  an  evolving  materiel  system  are 
determined,  and  when  and  by  whom  these  decisions  are  made. 
This  portion  of  the  effort  defines  the  critical  MPT 
parameters  which  must  be  transmitted  to  designers  to  ensure 
control  of  system  MPT  impacts. 

2.  Identify  the  means  by  which  critical  MPT  decisions  can  most 
effectively  be  transmitted  to  designers  so  that  the 
decisions  and  related  information  and  technologies  are 
effectively  utilized  by  designers. 


This  part  of  the  work  identifies  the  characteristics  or 
attributes  of  the  required  "common  language." 

3.  Determine  the  best  means  for  ensuring  that  system  designers 
in  fact  understand  the  parameters  communicated  to  them  and 
utilize  those  parameters  and  associated  data  and  techniques 
in  the  design  process.  Additionally,  identify  how  the 
ultimate  impact  on  system  MPT  characteristics  of  imparting 
required  MPT  parameters  to  designers  can  be  determined. 

This  portion  of  the  effort  outlines  a  verification  strategy 
for  ensuring  that  the  "common  language"  communications  are 
effective. 

The  remainder  of  this  report  discusses  the  general  approach  taken 
in  analyzing  and  investigating  these  three  critical  issues,  and  the 
findings  and  conclusions  of  the  analysis  effort.  Additionally,  a 
concluding  section  is  presented  which  discusses  in  some  detail  future 
developments  needed  to  further  develop  and  implement  the  "common 
language"  approach  in  order  to  control  materiel  system  MPT  impacts. 


APPROACH 


In  order  to  identify  the  attributes  of  a  common  language  for 
communication  of  Manpower,  Personnel,  and  Training  (MPT)  Information 
between  those  individuals  and  organizations  within  the  government  which 
conceptualize  and  utilize  new  materiel  systems  (planners/users)  and 
members  of  the  engineering  design  community  who  operationalize  materiel 
systems  in  hardware  and  software  (designers),  several  successive, 
incremental  activities  were  performed.  Each  activity  built  upon  the 
collective  results  of  previous  activities,  and  led  into  successor 
activities  directly,  to  ensure  that  all  findings  were  interrelated  and 
compatible.  The  activities  performed  were: 

1.  Identify  types  of  decisions  made  in  the  materiel  system 
acquisition  process  which  are  relevant  to  the  life  cycle 
MPT  Impacts  of  a  materiel  system. 

2.  From  the  decisions  identified  in  the  previous  activity, 
select  the  decisions  which  have  the  greatest  potential 
impact  upon  MPT  issues  during  the  life  cycle  of  a  materiel 
system  (critical  decisions). 

3.  Identify  the  point(s)  in  the  materiel  system  acquisition 
process  at  which  critical  decisions  are  made,  and  who  is 
responsible  for  these  decisions. 

4.  Determine  the  most  effective  means  of  communicating 
critical  MPT  decisions  to  the  engineering  design  community 
so  that  the  importance  and  potential  impact  of  MPT  issues 
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are  clearly  realized  by  designers  and  incorporated  into 
materiel  system  decisions. 

5.  Identify  means  of  verifying  that  designers  understood  and 
incorporated  MPT  data  and  requirements  in  design  decisions, 
and  that  these  data  and  requirements  have  the  desired 
long-term,  life  cycle  Impacts  on  the  MPT  characteristics  of 
materiel  systems. 

Procedures  which  were  followed  in  performing  these  activities  are 
summarized  in  the  paragraphs  below. 

The  first  activity  performed  was  to  examine  the  system  acquisition 
process  in  detail  to  determine  what  types  of  decisions  impact  the 
life  cycle  MPT  characteristics  of  materiel  systems  under  development. 
Since  the  system  acquisition  process  has  been  extensively  studied  and 
documented,  a  search  of  literature  was  performed  to  identify  public 
domain  and  Army  studies  and  reviews  which  could  provide  details  of  the 
acquisition  process  and  data  on  decision  making  regarding  MPT  issues. 
Due  to  the  limited  time  available  for  this  effort,  it  was  not  possible 
to  review  all  the  documents,  regulations,  directives,  and  study  reports 
which  were  identified  as  potentially  relevant.  Since  a  total  review 
was  not  possible,  attention  was  directed  toward  studies  and  analyses 
which  dealt  with  MPT  issues  in  system  acquisition,  rather  than  with 
source  documents  which  describe  the  ideal  form  of  the  system  acquisi¬ 
tion  process.  It  was  felt  that  such  study  and  analysis  reports  would 
provide  more  insight  into  the  reality  of  the  system  acquisition  process 
than  would  another  review  of  the  idealized  details  of  the  process. 
Documents  reviewed  in  this  activity  are  listed  in  Appendix  A. 


An  initial  review  of  the  selected  documents  revealed  that  there 
are  a  great  many  decisions  made  at  a  variety  of  levels  during  the 
acquisition  process  which  have  potential  Impacts  upon  the  ultimate  W>T 
characteristics  of  a  materiel  system.  Many  of  the  decisions  identified 
in  this  "first  pass"  were  evaluated  as  being  relatively  molecular 
decisions,  which  only  in  the  aggregate  would  be  useful  by  or  communi¬ 
cable  to  materiel  system  designers.  The  decision  was  made  to  concen¬ 
trate  attention  and  effort  on  MPT- imp acting  decisions  that  can  be 
"visible"  and  meaningful  to  the  designer  and  can  Influence  design 
decisions  both  at  the  system  design  and  component  design  levels,  rather 
than  on  the  "lower-level"  decisions  which  "feed"  major  MPT  characteris¬ 
tics  and  requirements.  Several  subsequent  reviews  of  source  documents 
led  to  an  increasingly  focused  "picture"  of  decisions  and  issues  which 
are  of  greatest  importance  to  life  cycle  MPT  impacts. 

The  decisions  which  were  identified  during  the  review  of  documents 
was  eventually  consolidated  into  a  list  which  contained  major 
decision-making  activities  and  processes  which  occur  in  system  acquisi¬ 
tion  with  potential  MPT  Impact,  through  the  full-scale  engineering 
development  phase  of  system  development.  As  this  list  was  compiled, 
the  points  in  the  system  acquisition  process  where  each  decision  is 
made  or  refined,  and  the  agency  responsible  for  each  decision  were 
Identified  and  associated  with  the  decision  items.  Attention  was 
directed  to  early  phases  of  system  acquisition,  since  decisions  in 
later  phases  (especially  production  and  deployment  of  a  materiel 
system)  are  of  little  importance  to  the  overall  design  of  the  materiel 
system,  which  is  usually  relatively  complete  at  this  stage. 
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The  list  of  decisions,  decision  points,  and  decision  makers  was 
distributed  to  a  working  group  of  senior  ASA  personnel  for  review  and 
comment  prior  to  a  meeting  whose  purpose  was  to  select  the  most 
critical  MPT-impacting  decisions  from  the  candidate  list.  A  one-day 
meeting  of  the  working  group  resulted  in  a  consensus  as  to  which 
decisions  should  be  considered  most  critical  to  the  life  cycle  MPT 
Impacts  of  a  materiel  system.  During  the  same  meeting,  an  extensive 
discussion  of  methods  of  communicating  these  critical  decisions  to 
designers,  verifying  understanding  of  MPT  data,  and  incorporating  such 
data  into  design  decisions  was  held.  The  working  group  reached 
agreement  on  the  basic  parameters  of  means  of  communication  of  MPT 
issues  and  verification  approaches  during  this  discussion. 

Following  the  working  group  meeting,  the  basic  "common  language" 
parameters  were  further  refined,  and  a  list  of  major  characteristics  of 
the  communication  process  (both  from  the  government  to  designers  and 
vice  versa)  was  prepared.  These  characteristics  form  the  basis  of  the 
discussion  of  "common  language"  requirements  in  the  following  sections 
of  this  report. 


RESULTS  AND  CONCLUSIONS 


At  the  core  of  toblem  addressed  In  this  study  lies  the  fact 
that  future  materiel  systems  must  be  designed  to  function  with  an 
optimal  minimum  demand  on  human  resources  to  operate  and  maintain  the 
materiel  systems,  since  limits  on  available  personnel  will  only 
continue  to  increase  in  t.ie  future.  The  demand  for  minimum  use  of 
personnel  in  turn  mandates  that  the  design  of  materiel  systems  support 
this  requirement.  In  order  that  the  designers  of  materiel  systems 
create  systems  to  meet  specific  manpower  criteria,  the  designers  must 
be  aware  of  the  specific  criteria  to  be  met,  and  must  also  be  aware  of 
the  consequences  of  failing  to  meet  the  criteria.  Communication  of  MPT 
criteria  to  the  hardware  designer  therefore  must  incorporate  three 
basic  issues:  content  (what  to  communicate),  process  (how  to  communi¬ 
cate),  and  verification  (ensuring  effective  communication  has  been 
made) . 

To  understand  the  characteristics  of  the  communication  process 
discussed  below,  it  is  necessary  to  understand  the  motivations  and 
processes  of  hardware  or  materiel  systems  design.  Engineering  design 
of  a  system,  at  its  base,  consists  of  choosing  among  a  large  set  of 
alternative  approaches,  to  develop  a  system  that  performs  a  defined  set 
of  functions.  Limitations  can  be  and  are  introduced  in  the  process  of 
making  design  choices  between  alternatives,  which  effectively  bound  or 
constrain  the  choices  available  to  the  designer.  The  set  of  functions 
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to  be  performed  by  the  final  design  represents  the  broadest  possible 
constraint  on  design,  since  efficient  engineering  Includes  only  those 
components  and  capabilities  which  are  needed  to  cause  the  system  to 
meet  Its  performance  requirements.  Constraints  at  many  different 
levels  are  typically  introduced  In  the  design  of  a  materiel  system. 

For  example,  a  requirement  may  exist  that  a  system  draw  no  more  than  a 
certain  amount  of  power  in  operation,  or  that  only  a  certain  volume  be 
occupied  by  the  system.  These  requirements  constrain  the  designer  to 
the  use  of  low-power  components,  and  either  low-volume  components  or 
high  component  density,  respectively.  On  another  level,  it  may  be 
required  that  a  system  incorporate  displays  which  can  be  read  in  direct 
sunlight.  This  requirement  constrains  the  designer  to  utilize  only 
display  technologies  with  sufficient  brightness,  contrast,  etc.  to  be 
read  in  the  sun.  Within  each  set  of  constraints  on  system  characteris¬ 
tics,  however,  the  designer  typically  has  a  variety  of  choices  which 
will  produce  equivalent  functional  results.  Conversely,  if  no 
constraints  exist  with  regard  to  a  particular  aspect  of  design,  the 
choice  possibilities  which  will  produce  equivalent  functional  designs 
are  quite  broad. 

The  above  discussion  must  be  considered  along  with  other  factors 
to  arrive  at  a  complete  picture.  The  designer  is  not  only  faced  with 
the  problem  of  producing  a  system  with  the  required  functional  quali¬ 
ties,  but  also  with  problems  of  cost  and  availability  of  components  to 
implement  the  various  possible  design  alternatives,  standard  engineer¬ 
ing  and  manufacturing  practices  and  tooling  which  must  be  followed,  and 
the  need  to  produce  the  final  system  at  a  profit  (the  larger,  the 
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better).  Each  of  these  and  many  other  variables  act  as  constraints 
upon  the  designer,  who  must  simultaneously  meet  or  approximate  all  of 
the  constraints  Imposed  while  at  the  same  time  producing  a  system  with 
the  required  capabilities  and  functional  qualities.  The  major  point  of 
this  exposition  Is  that,  given  firm  constraints,  a  designer  will 
attempt  to  design  a  system  within  those  constraints,  but  in  areas  where 
no  constraints  are  levied,  the  least  costly  and  time-consuming 
approaches  will  be  chosen  and  followed  with  little  regard  to  the 
peripheral  consequences  of  those  approaches,  as  long  as  the  firm 
constraints  remain  satisfied.  The  above  is  a  gross  oversimplification, 
of  course,  because  it  effectively  Ignores  the  complex  tradeoffs  that 
occur  In  the  design  process  when  many  contraints  must  be  simultaneously 
met.  The  point  is  clear,  however:  given  constraints,  the  designer 
will  design  to  meet  those  constraints,  but  in  unconstrained  areas  where 
choices  abound,  the  least  costly  approach  will  be  adopted  with  little 
regard  to  consequences  outside  explicit  constraints,  as  long  as  the 
basic  performance  parameters  of  the  system  are  met. 

As  an  example,  consider  the  designer  who  is  required  to  design  a 
relatively  slow  switching  network  with  no  other  constraints  (power, 
volume,  etc.  are  considered  immaterial).  The  designer  is  faced  with  a 
choice  between  simple  triode  vacuum  tubes  and  transistors  as  the 
primary  switching  elements  in  this  network,  but  knows  that  tubes  (in 
this  application)  last  20  times  as  long  as  transistors,  but  cost  three 
times  as  much  per  switching  element.  Further,  tubes  can  be  installed 
in  sockets,  but  the  individual  transistors  have  to  be  soldered  to 
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printed-circuit  boards  (for  the  sake  of  this  argument;  transistor 
sockets  also  exist).  The  network  will  perform  to  specification  with 
either  kind  of  component.  Which  component  will  the  designer  choose, 
given  no  other  constraints?  We  suspect  that  transistors  will  be 
chosen,  because  they  are  cheaper  (initially)  per  unit  item,  do  not 
require  mounting  sockets  (they  are  soldered  in),  consume  less  power 
(implying  a  smaller,  less  expensive  power  supply),  and  can  be  packed 
more  tightly  per  unit  volume.  Consider,  however,  the  impacts  on  main¬ 
tainability  of  this  simple  choice.  When  the  switching  network  fails, 
the  effort  to  isolate  the  failure  to  one  defective  component  is  about 
equivalent  for  tubes  and  transisitors,  given  an  efficient  troubleshoot¬ 
ing  strategy,  test  equipment,  etc.  The  effort  to  replace  a  defective 
transistor  is  much  greater  than  that  to  replace  a  tube,  since  replacing 
a  tube  requires  only  unplugging  the  defective  tube  and  substituting  a 
new  tube  to  effect  the  repair;  with  a  transistor,  the  defective  compo¬ 
nent  must  be  unsoldered  and  removed;  the  new  component  protected  with 
heat  sinks,  and  then  soldered  back  into  the  circuit  board.  Replacing  a 
transistor  therefore  is  much  more  time  consuming  (and  problem-prone) 
than  replacing  a  tube.  Further,  the  transistors  have  only  one- 
twentieth  the  expectable  life  of  tubes,  requiring  twenty  times  as  many 
replacement  actions  (on  the  average)  as  tubes  over  the  life  cycle  of 
the  switching  network.  The  network  using  tubes  is  clearly  more 
maintainable  than  that  using  transistors,  yet  the  "better"  engineering 
solution  of  using  transistors  is  chosen  because  no  constraints  were 
placed  on  system  maintainability. 
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While  the  above  is  a  simplified  example,  it  does  serve  to  illus¬ 
trate  the  point  that  designers  tend  to  meet  explicit  requirements  or 
constraints  (or  parameters,  etc.)  which  are  levied  on  the  ultimate 
system  being  designed,  but  give  relatively  little  attention  to  the 
consequences  of  design  characteristics  vrtiich  do  not  impact  the  attain¬ 
ment  of  system  performance  requirements  or  cause  explicit  constraints 
to  be  violated.  This  argument  can  be  logically  extended  to  include 
portions  of  the  total  system  which  are  not  hardware;  i.e.,  the  person¬ 
nel  and  training  components  of  a  system.  If  no  limits  or  constraints 
are  placed  on  the  impact  of  a  system  design  on  personnel  or  training, 
then  the  design  choices  made  during  evolution  of  the  materiel  system 
will  condition  the  functions,  numbers,  characteristics,  and  qualifica¬ 
tions  of  personnel  required  to  operate  and  maintain  the  system,  and  the 
amounts  and  kinds  of  training  required  for  personnel  to  be  able  to 
operate  and  maintain  the  system.  Conversely,  If  specific  constraints 
upon  the  manpower  and  training  impacts  of  a  system  are  provided  to  the 
designer,  in  addition  to  system  functional  and  performance  require¬ 
ments,  these  constraints  will  condition  hardware  design  choices  by  the 
designer  at  both  the  overall  system  and  component  levels  of  design  so 
as  to  meet  all  of  the  criteria  simultaneously.  It  is  common  practice 
in  materiel  system  acquisition  to  specify  and  constrain  the  performance 
parameters  and  other  designated  characteristics  of  the  hardware  portion 
of  the  system.  Designers  manage  to  develop  hardware  systems  which 
usually  meet  strictly  materiel  performance  objectives,  under  such 
constraints.  It  is  reasonable  to  assume,  then,  that  if  designers  also 
have  the  Impacts  of  their  designs  constrained  with  respect  to  impacts 


upon  the  "other"  side  of  the  total  system— manpower  and  training 
requirements— they  will  be  able  to  produce  effective  materiel  systems 
which  do  not  violate  explicit  MPT  constraints. 

Following  the  reasoning  above.  It  is  concluded  that  the  most 
effective,  understandable,  and  verifiable  means  of  communicating  criti¬ 
cal  information  regarding  MPT  requirements  and  decisions  to  materiel 
system  designers  is  through  the  provision  of  explicit  constraints  upon 
personnel  and  training  characteristics  of  the  total  system,  on  a  par 
with  strictly  materiel  requirements  such  as  firepower,  range,  speed, 
survivability,  and  so  forth,  as  system  performance  parameters.  In 
essence,  the  designer  should  be  given  clear  limits  on  the  requirements 
for  personnel  and  training  associated  with  the  materiel  system  under 
development,  just  as  he  is  provided  with  performance  parameters  for 
hardware,  and  constrained  to  meet  MPT  goals  as  well  as  hardware 
performance  goals.  Thus,  the  designer  must  be  placed  in  the  position 
of  "designing  to  constraint"  not  only  in  hardware,  but  in  a  total 
system  development,  including  the  materiel  system  and  the  people  who 
operate  and  maintain  that  system. 

This  conclusion  leaves  three  basic  points  unanswered,  however. 
These  are: 

1.  What  aspects  of  manpower  and  training  requirements  (or 
decisions  on  the  part  of  the  government)  should  be  commun¬ 
icated  to  the  designer  to  constrain  materiel  system 
design? 

2.  How  should  constraints  be  communicated  to  the  designer  to 
ensure  understanding  of  the  criticality  and  nature  of  the 


constraints  and  compliance  with  the  constraints  in 
design? 

3.  How  can  the  government  verify  that  the  designer  understood 
and  complied  with  the  constraints  provided  and  that  the 
constraints  have  the  desired  life  cycle  MPT  impacts  on 
system  requirements? 

Discussion  of  each  of  these  critical  issues  form  the  remainder  of  this 
section  of  the  report. 

Critical  MPT  Decisions 

Review  and  study  of  the  system  acquisition  process  (SAP)  in  early 
stages  of  this  effort  led  to  preparation  of  a  list  of  decisions  involv¬ 
ing  MPT  issues,  the  phases  of  the  SAP  where  decisions  are  initially 
made  or  refined  based  on  experience,  and  identification  of  the  agencies 
responsible  for  those  decisions.  This  list  is  reproduced  as  Appendix  B 
of  this  report.  A  major  finding  of  the  review  of  the  SAP  was  that 
decisions  made  before  full-scale  engineering  development  of  a  prospec¬ 
tive  system  begins  typically  remove  80-90  percent  of  the  original 
degrees  of  freedom  in  system  MPT  issues  (Fulkerson,  1974).  Since 
decisions  made  early  in  the  SAP  have  the  most  potential  influence  upon 
system  design,  most  of  the  emphasis  on  identifying  decision  areas  and 
decision  points  was  concentrated  on  early  phases  of  the  SAP  (through 
advanced  development  and,  to  an  extent,  full-scale  development).  One 
of  the  major  conclusions  of  this  analysis  was  that  initial  decisions 
based  on  estimates  and  analysis  of  comparison  fielded  systems,  and  made 


early  in  the  SAP,  tend  be  to  refined  by  later  experience,  but  are 
rarely  overturned  (O'Connor,  Fairall,  and  Birdseye,  1982).  It  is 
recognized  that  decisions  at  early  SAP  phases  tend  to  be  general, 
rather  than  specific,  which  leads  to  a  reluctance  to  put  the  decisions 
forth  in  requirement  documents  such  as  the  LOA,  CFP,  and  ROC.  Even 
though  general,  decisions  regarding  MPT  issues  at  early  stages  of  the 
SAP  are  most  likely  to  be  critical  to  the  design  of  hardware.  The 
designer  should  be  made  aware  of  these  decisions  from  the  very  outset 
of  the  design  process,  rather  than  having  to  "retrofit"  a  hardware 
design  to  accommodate  MPT  decisions  after  many  specific  design 
decisions  have  been  made.  Thus,  if  even  very  general  MPT  parameters 
can  be  communicated  to  a  designer  at  the  beginning  of  the  design 
process,  the  general,  broad  parameters  may  be  more  potent  in  influenc¬ 
ing  design  to  meet  desired  MPT  characteristics  than  will  extremely 
specific,  detailed  data  which  may  be  developed  only  after  one  or  more 
iterations  of  design  have  occurred.  It  is  considered  critical  that  MPT 
parameters  be  introduced  into  materiel  system  design  from  the  first 
exposure  of  the  designer  to  the  materiel  system  concept  (generally, 
this  occurs  when  the  Statement  of  Work  (SOW)  for  advanced  development 
contracts  is  prepared  and  distributed  as  part  of  an  RFP). 

Under  the  assumption  that  the  earliest  possible  introduction  of 
MPT  constraints  can  have  the  greatest  impact  on  design,  even  though 
constraints  are  broad  and  general,  the  process  of  evolving  MPT  data  was 
reexamined.  The  purpose  of  the  reexamination  was  to  identify  critical 
early  decisions  which  are  appropriate  for  use  as  design  constraints  or 
parameters.  The  criteria  used  for  selection  of  these  critical 
decisions  were  as  follows: 


1.  Data  are  generated  to  support  first  approximations  to  these 
decisions  during  the  concept  exploration  phase  of  system 
acquisition,  in  at  least  detailed  concept  form.  Each  of 
the  decisions  selected  is  at  least  nominally  addressed  by 
analysis  or  studies  before  the  Concept  Formulation  Package 
(CFP)  is  finalized. 

2.  The  decision  area  must  be  one  vrtn'ch  can  be  stated  as  at 
least  a  loosely  quantitative  parameter  (numbers  of  people, 
weeks  of  training,  mean  time  to  repair,  etc.)  based  on 
initial  estimates  and  possibly  refined  later  in  the 
acquisition  process. 

3.  The  decision  area  must  be  ultimately  verifiable  in  terms  of 
MPT  life  cycle  impact  by  direct  comparison  of  available 
manpower  and  training  data  to  requirements  levied  upon  the 
materiel  system  designer. 

4.  The  decision  area  must  deal  with  overt,  ultimate  character¬ 
istics  of  the  materiel  system  which  have  major  long-term 
MPT  impacts. 

Two  general  areas  were  identified  as  sources  of  MPT  constraints 
for  designers.  The  first  area  includes  direct  estimates  of  MPT 
parameters  which  can  be  stated  in  terms  of  desirable  personnel  and 
training  system  characteristics  for  a  materiel  system.  The  second  area 
deals  with  characteristics  of  the  materiel  system  itself  which  can 
indirectly  act  to  influence  ultimate  MPT  requirements.  Taken  together, 
the  early  decisions  made  in  these  areas  have  the  greatest  potential 
impact  on  life  cycle  MPT  requirements  of  a  system  under  development. 


The  parameters  or  characteristics  identified  in  these  areas  as 
having  the  greatest  potential  effect  on  system  life  cycle  MPT 
requirements  are  summarized  in  Table  1.  It  is  recognized  that  these 
parameters  are  stated  at  a  rather  global  level,  but  it  is  believed  that 
this  level  of  expression  is  likely  to  be  the  most  effective  way  of 
causing  the  designer  to  be  aware  of  MPT  constraints  from  the  very 
outset  of  the  design  process.  Further,  these  parameters  are  stated  at 
a  level  of  detail  which  is  likely  to  be  available  even  during  early 
stages  of  system  acquisition,  as  a  result  of  concept  exploration 
studies  and  analyses,  and  as  such  are  available  as  early  constraint 
items  for  use  in  advanced  development  procurements  (there  is  no 
defensible  reason  to  ignore  MPT  Impacts  at  this  stage,  even  though 
hardware  concepts  are  being  evaluated  at  the  brassboard  stage— if  a 
system  continues  to  production,  the  manpower  and  training  requirements 
inherent  in  the  basic  hardware  design  choices  will  carry  forward  from 
the  initial  design). 


Communicating  the  Decisions  (Common  Language  Attributes) 

Given  that  decisions  and  parameters  are  available  to  be  communi¬ 
cated  to  a  designer  in  order  that  his  design  choices  be  constrained  to 
certain  ultimate  MPT  impacts,  a  means  must  exist  to  communicate  those 
constraints  to  the  designer.  To  identify  potentially  effective 
channels  for  such  communication,  a  review  of  the  existing  formal 


Table  1 


Critical  Decisions  Made  in  Materiel  System  Acquisition  Having  the 
Greatest  Potential  Life-Cycle  Manpower,  Personnel,  and 
and  Training  (MPT)  Impacts  on  System  Design 


Decisions  Describing  Desirable  MPT  Characteristics  of  Materiel  System 

-  Allocation  of  system  functions  to  operators  (versus  hardware) 

-  Number  of  operator  personnel  per  copy  of  hardware  system 

-  Skill  levels  and  MOSs  for  operator  personnel 

-  Desired  training  time  and  milieu  for  operator  personnel  (to 
minimum  proficiency) 

-  Operator  training  device  requirements  (number  and  purpose) 

-  Unit  structures  (TOE)  desirable  for  operation  and  support  of 
materiel  system 

-  Desired  number  of  maintenance  personnel  per  level  of 
maintenance  to  support  one  copy  of  materiel  system  (maintenance 
manhour  requirements  is  a  rough  equivalent) 

-  Desired  training  time  and  milieu  for  each  category  of 
maintenance  personnel 

-  Maintenance  training  device  requirements  (number  and  purpose) 
Decisions  Describing  Materiel  System  Characteristics  That  Influence 

m r - -  - 


System  maintenance  concept:  number  of  levels  of  maintenance 
structure  and  allocation  of  maintenance  functions  to  levels 

Desired  reliability  and  availability  levels  of  overall  materiel 
system,  subsystems,  and  support  systems 

Desired  maintainability  characteristics  of  materiel  system 
(allowable  downtime  time  to  repair,  built-in  or  automated  test 
capabilities  and  requirements,  etc.) 


channels  of  communication  between  the  government  and  designers/ 
contractors  was  performed  to  determine  whether  manpower  and  training 
constraints  might  be  Implemented  effectively  through  such  channels. 
Emphasis  in  this  review  was  on  the  following  considerations: 

1.  An  effective  means  of  imparting  MPT  constraints  to 
designers  should  parallel  the  means  by  which  other 
constraints  and  requirements  (i.e.,  materiel  system 
characteristics)  are  communicated. 

2.  The  means  of  communication  should  provide  clear  emphasis 
that  MPT  constraints  are  at  least  equivalent  to  materiel 
system  performance  requirements  in  importance,  and  that  the 
two  areas  are  interdependent  aspects  of  the  total  system  to 
be  designed. 

3.  The  means  of  communication  should  incorporate  ways  to 
evaluate  whether  MPT  constraints  and  their  intent  are 
understood  by  the  designer. 

A  summary  of  the  results  of  the  effort  to  identify  and  define  common 
language  attributes  is  presented  as  Table  2.  This  table  identifies 
each  attribute  and  presents  a  brief  explanation  of  the  attribute.  In 
addition,  the  manner  in  which  each  attribute  has  been  dealt  with  in  the 
past  is  discussed,  and  possible  applications  of  the  attribute  to  future 
materiel  system  procurements  are  set  foth  in  the  column  headed 
"Application  (Past/Future)." 

Only  one  existing  channel  of  communication  between  the  government 
and  system  designers/contractors  which  is  common  in  all  materiel  system 
acquisitions  and  fulfills  the  characteristics  listed  above  was  identi¬ 
fied.  This  channel  is  the  system  specification  document  which  composes 
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a  major  portion  of  the  Statement  of  Work  for  materiel  system  procure¬ 
ments.  The  specification  document  contains  requirements  for  materiel 
system  performance  in  terms  of  detailed  criteria  which  the  system  must 
meet  in  order  to  fulfill  its  mission.  In  this  context,  it  is  possible 
to  introduce  explicitly  MPT-impacting  constraints  on  an  equivalent 
level  with  materiel  system  performance  requirements  as  part  of  the 
system  performance  specification.  Since  explicit  response  to  all 
aspects  of  requests  for  proposals  Is  typically  required  of  a  prospec¬ 
tive  contractor,  an  opportunity  to  evaluate  a  designer /offeror's  under¬ 
standing  of  MPT  constraints— in  his  proposal— is  present.  Thus,  it  is 
considered  possible  to  make  explicit  MPT  constraints  a  part  of  system 
specifications  governing  the  designer. 

It  is  recognized  that  the  idea  of  placing  explicit  W>T  constraints 
and  requirements  In  system  performance  specification/RFPs  may  cause 
some  uneasiness  on  the  part  of  readers  of  this  report.  This  In  an 
understandable  reaction,  since  there  is  certain  to  be  some  resistance 
on  the  part  of  designers/contractors  to  being  constrained  to  particular 
manpower  and  training  impacts  of  system  designs.  In  order  to  be  effec¬ 
tive,  MPT  constraints  MUST  be  stated  as  explicit  performance  require¬ 
ments  for  the  total  materiel  system  to  be  developed.  No  other  means  of 
making  MPT  constraints  effective  is  apparent.  While  there  are  many  al¬ 
ternative  ways  of  presenting  MPT  requirements/constraints  to  designers, 
the  only  likely  means  of  causing  the  constraints  to  be  effective  is  to 
require  that  the  system  comply  with  those  constraints;  the  only  avail¬ 
able  way  to  effect  this  outcome  is  to  make  compliance  with  the 
constraints  a  contractual  requirement.  Other,  less  formal  means  of 


presenting  desired  MPT  constraints  and  information  to  designers  cannot 
have  the  force  and  compluslon  to  mandate  compliance  and  thus  to  cause 
the  constraints  to  truly  constrain. 


i 
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Having  reached  the  conclusion  that  the  most  ultimately  effective 
means  of  imparting  MPT  information  to  designers  is  to  include  explicit 
constraints  upon  various  MPT  parameters  of  the  total  system  to  be 
designed,  as  provisions  of  system  performance  specifications  in  devel¬ 
opment  contracts,  some  additional  attributes  of  constraints  which  will 
help  to  ensure  effective  communication  can  be  discussed.  First,  MPT 
constraints  should  overtly  deal  with  specific  parameters  of  the 
personnel /materiel  system,  rather  than  with  bodies  of  data  such  as 
specifications,  standards,  regulations,  procedural  guides,  or  hand¬ 
books,  which  describe  ways  in  which  the  constraints  can  be  met,  or 
techniques  (i.e.,  "tools").  A  great  many  "tools"  for  dealing  with  MPT 
aspects  of  systems  now  exist  (e.g.,  ISD  handbooks,  human  factors 
engineering  guides,  system  analysis  procedures,  etc.),  and  are 
typically  addressed  or  referenced  in  materiel  system  specification 
packages.  Therefore,  the  designer  is  already  at  least  nominally 
provided  with  many  of  the  "tools"  to  be  used  in  complying  with  MPT 
constraints.  The  question  of  developing  means  to  help  the  designer 
select  the  appropriate  "tools"  to  aid  in  meeting  MPT  constraints  is  an 
important  one,  but  development  of  such  a  means  Is  beyond  the  scope  of 
this  effort.  Explicit  constraints  dealing  with  very  specifically 
defined,  but  general  MPT  characterlslcs  (listed  Table  1)  must  be 
provided  in  order  to  control  the  MPT  impacts  of  system  design. 
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Next,  a  rationale  for  the  choice  of  particular  MPT  constraint  or 
parameter  values  must  be  provided  to  the  designer  in  order  to  justify 
and  explain  the  particular  choices  of  constraints  which  have  been 
levied.  If  a  rationale  Is  not  provided,  designers  will  not  understand 
the  importance  of  the  contralnt;  i.e.,  they  will  not  understand  "why" 
the  constraint  has  been  levied,  therefore,  they  may  ignore  the 
constraint.  The  rationale  for  most  of  the  parameters  which  would  be 
constrained  can  be  captured  during  mission  area  analysis  and  concept 
formulation  phases  of  the  acquisition  process  and  presented  as  justifi¬ 
cation  for  constraint  value  choices.  Mission  area  analysis  should 
identify  MPT-related  deficiencies  or  problems  in  present  systems  which 
a  materiel  system  under  development  will  replace;  these  deficiencies 
can  form  the  basis  for  development  of  f*PT  constraints  during  concept 
formulation.  The  results  of  these  developments  form  the  basic  ration¬ 
ale  for  MPT  constraint  choices.  It  is  considered  vital  for  the 
designer  to  understand  not  only  what  constraints  are  levied  upon  the 
MPT  characteristics  of  the  materiel  system  he  is  to  design,  but  also 
the  derivation  and  Intrinsic  Importance  of  those  requirements. 

A  further  desirable  characteristic  of  MPT  constraints  to  be  levied 
on  the  designer  Is  that  the  constraints  be  clearly  quantitative.  A 
quantitative  goal  {number  of  operators,  number  of  weeks  of  training, 
maximum  number  of  allowable  annual  maintenance  manhours  per  system 
copy,  etc.)  is  clear  and  easy  to  understand,  and  provides  an  uncompro¬ 
mised  criterion.  Qualitative  statements  of  constraints  (i.e.,  "the 
system  shall  be  designed  to  operate  with  a  minimum  number  of 
personnel")  are  less  easy  to  understand  as  constraints  and  leave 
considerable  mid  undesirable  latitude  to  the  designer.  Permitting 


such  latitude  would  totally  defeat  the  purpose  of  constraining  the  MPT 
characteristics  of  a  system  under  design;  in  fact,  such  pseudo- 
constraints  are  presently  used  in  materiel  system  design  contractual 
documents,  with  disappointing  results. 

Yet  another  attribute  of  MPT  constraints  should  be  guidance  as  to 
how  the  constraints  can  be  satisfied  during  the  design  and  evolution  of 
a  materiel  system.  As  mentioned  previously,  many  “tools"  and  techni¬ 
ques  for  examining  and  analyzing  various  MPT  implications  and  conse¬ 
quences  of  materiel  system  design  characteristics  are  available.  These 
"tools"  are  typically  in  the  form  of  regulations,  standards,  direc¬ 
tives,  etc.,  and  often  are  contradictory  in  purpose,  procedures, 
recommendations,  requi rements,  and  so  forth.  A  consequence  of  this 
situation  is  that  the  designer  has  no  clear  guidance  for  dealing  with 
MPT  issues  during  design.  This  results  in  only  cursory  attention  to 
MPT  issues  (since  the  designer  does  not  have  a  clear  picture  of  how  to 
get  to  the  desired  results)  and  possibly  "pencil -whipping"  of  required 
documentation  of  MPT  investigations  during  design.  It  was  mentioned 
earlier  that  development  of  a  "roadmap"  delineating  "tools"  for  helping 
the  designer  meet  MPT  constraints  on  design  is  beyond  the  scope  of  the 
present  effort.  It  is  considered  of  major  importance  in  future 
efforts,  however,  that  such  a  "roadmap"  be  developed  and  made  available 
to  designers  along  with  explicit  constraints  on  MPT  characteristics  of 
system  designs. 

A  characteristic  of  the  constraint  set  on  MPT  impacts  which  was 
implied  but  not  stated  previously  was  that  compliance  with  the  explicit 
constraints  be  ultimately  verifiable  by  examining  the  characteristics 
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of  the  materiel  system  developed,  in  the  operational  environment.  This 
characteristic  ties  closely  to  that  of  the  desired  quantitative  nature 
of  constraints.  If  it  is  initially  specified  that  a  materiel  system  be 
designed  (for  example)  to  be  fully  operational  using  x  number  of 
operator  personnel  in  ^  defined  positions,  it  is  vital  to  be  able  to 
examine  the  operational  effectiveness  of  the  system  under  those 
conditions  to  determine  if  the  constraints  were,  in  fact,  met.  This 
represents  ultimate  verification  of  the  success  and  impact  of  the 
constraints . 

Finally,  in  order  to  be  effective,  constraints  must  be  associated 
with  effective  consequences  for  failure  to  meet  the  constraints.  This 
is  another  topic  which  may  cause  some  uneasiness  in  many  quarters,  akin 
to  the  overall  concept  of  placing  explicit  MPT  constraints  in  the 
requirements  and  specifications  of  system  development  RFPs.  It  is  a 
hard  psychological  and  practical  fact,  however,  that  behavior  cannot  be 
modified  without  consequences  to  unwanted  behavior.  In  this  case,  the 
"unwanted  behaviors"  are  failure  to  give  consideration  and  attention  to 
the  MPT  impacts  of  a  system  under  design,  coordinate  with  engineering 
design  and  materiel  system  performance  issues.  A  trend  has  arisen  in 
recent  years  in  the  direction  of  including  performance  warranties  in 
strictly  hardware-oriented  aspects  of  materiel  system  procurement. 

This  approach  introduces  explicit  and  overt  economic  consequences  to 
the  designer  and  producers  of  materiel  systems,  which  hopefully  causes 
more  detailed  attention  to  be  paid  to  materiel  system  factors  that 
could  cause  the  overall  system  to  fail  to  meet  warranted  performance 
characteristics.  It  seems  reasonable  to  introduce  similar  consequences 


to  failures  to  meet  MPT  constraints.  For  example,  if  minimum  profic¬ 
iency  training  time  and  cost  for  operators  of  a  materiel  systen  exceed 
constraints  levied  from  the  outset  of  the  design  process,  the  system 
designer  could  be  forced  to  absorb  the  portion  of  training  costs  that 
exceed  those  that  would  exist  if  specified  constraint  values  had  been 
met.  This,  of  course,  supposes  that  the  constraints  imposed  are 
reasonable  and  achievable.  It  is  a  risk  in  using  MPT  constraints  to 
influence  materiel  system  design  that  the  imposed  constraints  may  not 
be  achievable,  given  other  desired  characteristics  of  the  system  and 
its  performance  objectives.  There  are,  however,  a  number  of  opportuni¬ 
ties  early  in  the  system  acquisition  process  vrttere  it  is  possible  to 
detect  unreasonable  constraints,  the  most  obvious  being  the  materiel 
concept  tradeoff  analyses  conducted  during  the  development  of  the  CFP 
in  the  concept  exploration  phase  of  acquisition.  At  this  point, 
mission  performance  parameters,  technology  factors,  logistic  implica¬ 
tions,  and  manpower  and  training  considerations  are  traded  off  to 
arrive  at  selection  of  a  best  technical  approach  for  further  develop¬ 
ment  in  the  advanced  development  phase  of  acquisition.  If  explicit 
attention  is  given  to  potential  MPT  requirements  and  constraints  during 
the  tradeoff  process,  it  seems  unlikely  that  genuinely  unachievable 
constraints  will  be  generated.  It  is  not  clear  to  what  extent  WT 
factors  are  considered  during  the  tradeoff  process  at  present,  but  is 
should  be  feasible  to  address  potential  MPT  constraints  during  this 
process,  to  ensure  that  unreasonable  constraints  are  not  introduced. 
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Verification 


Having  imposed  constraints  upon  the  MPT  Impacts  of  the  design  of  a 
materiel  system,  it  is  also  necessary  to  be  able  to  verify  that  the 
designer  understood  the  nature  and  implications  of  the  constraints 
imposed,  and  that  the  constraints  were  considered  in  making  design 
choices.  It  is  further  necessary  to  be  able  to  determine  whether  the 
constraints  were  ultimately  complied  with  and  had  the  desired  effects 
upon  the  MPT  characteristics  of  the  system.  These  three  verification 
problems  are  addressed  in  the  following  paragraphs.  A  summary  of  the 
verification  strategy  discussed  below  is  presented  graphically  in 
Figure  1. 

The  problem  of  verifying  the  ultimate  impact  of  constraints  on 
system  MPT  characteristics  is  the  most  straightforward  of  the  verifica¬ 
tion  issues,  and  so  will  be  dealt  with  first.  Verifying  that  a 
materiel  system  design  fully  complies  with  imposed  MPT  constraints 
cannot  be  done  until  production  versions  of  the  system  are  deployed  and 
integrated  into  the  Army  operational  inventory.  At  this  point, 
operational  training  of  personnel  to  operate  and  maintain  the  system 
has  taken  place,  and  experience  is  beginning  to  accumulate  regarding 
the  adequacy  of  performance  of  the  materiel  system  as  supported  by  Army 
personnel  in  its  mission  role.  In  the  operational  environment,  a 
materiel  system  comes  under  the  scrutiny  of  a  variety  of  measurement 
and  evaluation  systems  which  tap  personnel  requirements,  training 
requirements,  operational  effectiveness  of  the  materiel  system,  and  so 
forth.  Data  generated  by  the  various  measurement  systems  cai  be 
aggregated  to  create  a  composite  picture  of  the  true  operational  MPT 


parameters  of  the  system,  and  compared  to  the  original  MPT  constraints 
to  determine  whether  these  constraints  have  been  met.  The  operational 
performance  of  the  total  system  in  its  mission  role  must  be  considered 
along  with  evaluation  of  the  satisfaction  of  MPT  constraints,  however. 
If  the  overall  personnel /materiel  system  fails  to  meet  its  stated 
performance  goals,  yet  the  imposed  MPT  constraints  are  satisfied,  there 
is  the  possibility  that  inappropriate  MPT  constraints  in  some  manner 
contributed  to  such  a  failure.  Given  that  the  MPT  constraints  were 
given  appropriate  attention  during  system  concept  formulation,  and  that 
experience  with  other  materiel  systems  is  taken  into  account,  such  an 
outcome  will  not  be  likely. 

It  is  beyond  the  scope  of  the  present  effort  to  identify  data 
sources  and  means  of  aggregating  data  to  provide  a  detailed  methodology 
for  determining  whether  NPT  constraints  imposed  on  system  design  have 
the  desired  ultimate  impacts  upon  life  cycle  MPT  characteristics  of 
systems  under  development.  Evolution  of  such  a  methodology  must  await 
future  efforts.  The  point  of  the  above  discussion  is  clear,  however: 
in  order  to  measure  the  ultimate  impact  of  W’T  constraints,  the  actual 
MPT  characteristics  and  operational  effectiveness  of  the  fielded  system 
must  be  assessed  against  the  parameters  specified  as  constraints. 
Existing  evaluation  and  assessment  data  systems  at  least  nominally 
provide  data  which  can  be  utilized  to  identify  the  actual  MPT  charac¬ 
teristics  of  a  materiel  system  In  the  operational  inventory. 

The  problems  of  verifying  whether  designers  understand  the  nature 
and  Intent  of  MPT  constraints  and  whether  the  design  choices  made  by 
the  designers  are  in  fact  influenced  by  the  constraints  are  less 
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straightforward  than  evaluating  the  ultimate  impact  of  imposed 
constraints.  Since  It  has  been  suggested  that  communication  of 
constraints  to  designers  take  place  by  formal  means  which  are  presently 
established  (system  performance  specifications),  a  logical  source  of 
verification  information  is  through  formal  channels  of  communication 
from  the  designer  to  the  government,  associated  with  the  system 
development  effort. 

The  obvious  source  for  evaluating  the  contractor's  initial  under¬ 
standing  of  the  Intent,  purpose,  and  Importance  of  MPT-impacting 
constraints  is  the  technical  proposal  and  associated  supporting  docu¬ 
mentation  provided  by  the  prospective  designer  in  competitive  bidding. 
The  designer /offeror's  comprehension  of  the  importance  and  implications 
of  specific  constraints  regarding  the  MPT  impacts  of  the  system  can  be 
assessed  through  requiring  the  designer/offeror  to  set  forth  in  his 
proposal  the  initiatives  he  plans  to  implement  to  ensure  that  MPT 
constraints  are  considered  at  all  levels  and  phases  of  system  design. 
The  comprehensiveness  and  clarity  of  the  plans  set  forth  by  the 
designer /offeror  will  reflect  his  understanding  of  the  emphasis  placed 
on  MPT  Issues  and  impacts,  and  the  importance  of  MPT  considerations  as 
a  factor  in  total  system  design,  parallel  to  the  Importance  of  materiel 
system  performance  factors.  In  fact,  evidence  of  understanding  of  the 
intent  and  purpose  of  W>T  constraints  and  detailed  plans  to  ensure  that 
MPT  constraints  will  be  met  can  be  made  a  significant  portion  of  the 
evaluation  factors  for  award  of  the  prime  design/  development  contract 
for  a  materiel  system.  Failure  to  demonstrate  that  the  intent,  nature, 
and  Importance  of  MPT  constraints  has  been  considered  and  evaluated. 


and  efforts  to  comply  with  the  constraints  have  been  Incorporated  in 
planning  the  system  design  process,  will  weigh  against  the  designer/ 
offeror.  This  approach  to  ensuring  that  MPT  constraints  and  factors 
are  considered  by  designers  takes  advantage  of  a  system  which  is 
already  in  place  and  operational.  There  Is,  however,  one  potentially 
very  serious  problem  which  must  be  addressed  in  order  for  this  approach 
to  be  useful.  This  is  the  development  of  the  "roadmap"  linking 
potential  MPT  constraints  to  techniques  and  technologies  to  assist 
designers  in  meeting  those  constraints,  mentioned  earlier  in  this 
report.  In  order  for  the  designer  to  be  able  to  meet  MPT  impact 
constraints,  he  must  be  provided  a  reasonably  clear  picture  of  how 
those  constraints  can  be  satisfied  while  addressing  other  major  iosign 
issues,  notably  that  of  ensuring  that  the  materiel  system  meets  its 
performance  objectives.  It  is  critical,  then,  if  designers  are  to  be 
required  to  design  to  MPT  constraints,  usable  methods  of  employing 
available  techniques  to  evaluate  the  MPT  implications  of  evolving 
system  designs  be  known  to  the  designer.  Given  that  the  designer  is 
aware  of  the  existence  and  utility  of  techniques  to  assess  the  MPT 
impacts  of  designs  (not  always  or  even  frequently  the  case  at  present), 
explicit  plans  to  utilize  those  techniques  and  "tools"  can  be 
integrated  into  his  design  effort.  It  is  the  presence  of  such  plans  in 
the  designer/offeror's  material  system  design  proposal  which  can  be 
evaluated  to  assess  whether  designer/offerors  in  fact  comprehend  the 
nature.  Intent,  and  Importance  of  MPT  constraints. 

The  problem  of  verifying  that  designers  actually  consider  MPT 
constraints,  and  attempt  to  meet  these  constraints  (and  use  tools  for 


incorporating  MPT  information  into  design  decisions)  is  closely  coupled 
to  verifying  both  the  ultimate  impact  of  the  imposed  MPT  constraints 
and  the  designer's  understanding  and  comprehension  of  the  intent  and 
nature  of  the  constraints.  While  it  is  absolutely  vital  that  the 
designer  consider  MPT  impacts  and  constraints  in  the  design  process, 
and  that  these  constraints  genuinely  Influence  his  design  choices, 
verifying  that  the  designer  has  done  so  during  the  course  of  design  is 
a  complex  problem.  Again,  existing  requirements  for  formal  communica¬ 
tion  between  the  designer  and  the  government  may  provide  opportunities 
to  verify  whether  the  designer  In  fact  incorporates  MPT  constraints 
into  the  design  process. 

In  a  typical  contract  effort  to  design  a  materiel  system,  the 
designer  Is  required  to  produce  a  wide  variety  of  documentary  products 
which  substantiate  design  progress  and  the  characteristics  of  the 
system  design.  Since  the  designer  performs  many  tradeoff  evaluations 
in  the  course  of  a  design  effort,  it  may  be  feasible  to  examine  the 
factors  used  in  major  tradeoff  decisions  to  determine  whether  impact 
upon  MPT  factors  was  considered  In  the  tradeoff  process,  and  whether 
tradeoffs  resulted  in  design  decisions  which  trend  toward  satisfaction 
of  MPT  constraints.  An  example  of  such  a  tradeoff  would  be  the  process 
of  choosing  whether  to  use  common  test  equipment  versus  built  in 
automatic  test  facilities  for  fault  isolation  in  an  electronic  system. 
Both  solutions  are  potentially  manpower  and  training  intensive,  but  at 
different  levels:  use  of  common  test  equipment  implies  highly-trained, 
capable  personnel  interacting  extensively  with  the  prime  equipment  to 
perform  fault  isolation,  while  built-in  automatic  test  implies  a  lower 


requirement  for  direct  Interaction  with  the  prime  equipment,  by 
personnel  with  less  expertise  (and,  hence,  requiring  less  training). 

On  the  other  hand,  built-in  test  equipment  can  go  bad  itself,  requiring 
additional  trained  manpower  to  repair,  and  leaving  the  prime  system 
down  (since  there  is  no  way  to  perform  the  fault  isolation  tasks  that 
were  relegated  to  the  automated  test  equipment).  Also,  the  use  of 
built-in  test/automated  test  at  the  organizational  maintenance  level 
has  the  tendency  to  push  maintenance  workload  "up"  the  maintenance 
system  to  intermediate  and  depot  levels,  requiring  larger  numbers  of 
trained  personnel  (probably  more  highly  trained  than  at  the  organiza¬ 
tional  level)  at  higher  levels  of  maintenance,  additional  test  equip¬ 
ment,  etc.  The  choice  between  the  two  would  be  based  on  a  complex 
tradeoff  analysis  incorporating  considerations  of  reliability  (of  both 
prime  and  test  equipment),  system  maintenance  concept,  equipment 
availability  requirements,  manpower  demand  at  all  levels  of  mainte¬ 
nance,  and  training  requirements. 

Unless  specific  manpower  and  training  requirements  are  considered 
in  this  sort  of  tradeoff  (along  with  a  host  of  other  relevant  factors), 
the  implications  of  the  approach  selected  on  MPT  factors  will  remain 
undefined  well  into  subsequent  phases  of  design.  Requiring  documenta¬ 
tion  of  tradeoffs  to  include  the  specific  impacts  of  the  various  trade¬ 
off  alternatives  upon  manpower  and  training  requirements  represents  one 
feasible  approach  to  assessing  the  extent  to  which  designers  actually 
attempt  to  meet  Imposed  MPT  constraints.  There  are  a  number  of  formal 
communication  events  which  might  be  used  to  document  the  extent  to 


which  MPT  constraints  and  impacts  are  considered  in  design  decisions 
and  tradeoffs.  The  most  potentially  useful  of  these  events  for  assess¬ 
ing  whether  MPT  factors  are  considered  in  design  decisions  are  Interim 
Design  Review  Conferences.  At  these  conferences,  the  designer  presents 
specific  details  of  the  evolving  design  and  discussion  of  such  issues 
as  tradeoffs  performed,  the  results  of  those  tradeoffs,  problems 
encountered,  and  so  forth.  The  designer  can  be  required  to  demon¬ 
strate,  during  design  reviews,  that  critical  MPT  factors  have  in  fact 
been  considered  and  evaluated  during  system  design  tradeoffs,  and  that 
approaches  which  in  fact  tend  to  minimize  potential  MPT  demands  in  the 
ultimate  system  have  been  adopted.  While  it  may  not  be  (and  probably 
is  not)  feasible  or  cost-effective  for  the  desic"er  to  jointly  evaluate 
in  detail  the  impacts  of  all  tradeoff  decisions  on  MPT  factors,  trends 
of  designers'  decisions  with  respect  to  MPT  impact  can  be  identified  by 
examining  major  tradeoff  processes  and  outcomes.  Thus,  if  a  designer 
consistently  fails  to  include  consideration  of  MPT  impacts  in  major 
system  tradeoff  decisions  or  consistently  chooses  approaches  which 
imply  greater  demands  for  trained  manpower,  his  lack  of  sensitivity  to 
the  MPT  impact  of  his  design  will  be  evident. 


DISCUSSION 


A  central  problem  In  ensuring  that  materiel  system  designers  take 
manpower,  personnel  and  training  (MPT)  issues  into  account  in  the 
system  design  process  is  the  communication  of  the  government's 
decisions  about  the  allowable  impact  of  a  materiel  system  on  I^T 
requirements,  and  verifying  that  designers  incorporate  these  limits 
into  their  designs.  This  effort  has  addressed  this  problem  at  a 
preliminary,  general  level.  The  critical  categories  of  MPT  information 
which  should  be  addressed  have  been  defined,  it  has  been  determined 
that  these  decisions  will  be  most  effective  if  stated  in  terms  of 
system  performance  parameters  or  constraints,  and  general  approaches 
for  verifying  the  understanding  and  utilization  of  the  constraints  by 
designers  and  the  ultimate  impact  of  the  constraints  on  MPT  require¬ 
ments  have  been  addressed.  The  means  by  which  MPT  requirements  should 
be  communicated  to  designers  and  the  verification  approaches  identified 
form  an  outline  of  a  "common  language"  for  the  exchange  of  MPT  informa¬ 
tion  between  the  government  and  designers.  A  diagram  illustrating  the 
overall  concept  of  utilizing  the  "common  language"  to  communicate  MPT 
requirements  to  designers  and  verifying  designers'  understanding  and 
utilization  of  MPT  requirements  is  presented  as  Figure  2. 

It  must  be  emphasized  that  this  effort  represents  only  a  first 
approximation  to  the  definition  and  implementation  of  a  means  of 
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Common  Language"  Communication  Flows  In  Materiel  System  Acquisition 


LCSMM  PHASES 


Language"  Communication  Flows  in  Materiel  System  Acquisition  (cont.) 


controlling  the  impact  of  materiel  system  design  upon  the  ultimate 
requirements  for  manpower,  personnel,  and  training  of  a  total  system. 

A  number  of  critical  Issues  remain  to  be  addressed  in  order  to  define 
and  implement  an  effective  “common  language."  Two  critical  develop¬ 
ments  which  have  been  identified  in  the  course  of  performing  the 
present  work  are  discussed  below.  It  is  considered  absolutely  essen¬ 
tial  that  those  two  developments  be  undertaken  prior  to  implementing 
MPT  impact  constraints  in  the  design  process.  Those  developments  will 
provide  needed  tools  and  techniques  to  ensure  that  well -conceived  and 
achievable  MPT  constraints  are  formulated,  and  that  designers  have  the 
means  available  to  comply  with  the  constraints. 

1.  The  decision  process  leading  to  the  establishment  of  MPT 
requirements  early  in  the  system  evolution  process  (concept 
exploration)  is  not  well  defined  or  well  operationalized. 
Although  certain  developments  and  events  which  should 
provide  initial  data  on  which  to  base  MPT  decisions  are 
specified  as  part  of  the  LCSMM  process  (training  and 
logistic  support  analyses),  it  is  not  known  to  what  extent 
these  developments  produce  data  which  are  sufficiently 
comprehensive  and  complete  to  drive  MPT  decisions.  An 
investigation  of  the  quality  of  data  generated  during 
system  and  subsystem  concept  exploration  efforts  and  the 
applicability  of  this  data  to  MPT  decisions  would  provide 
resolution  of  this  question.  It  is  suspected  that  the 
emphasis  on  detailed  analyses  to  support  training  and 
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logistic  planning,  vrfiich  should  provide  basic  data  and 
estimates  for  establishing  MPT  requirements  and  con¬ 
straints,  varies  widely  across  system  developments.  It  is 
clear  from  examination  of  the  structure  of  the  LCSW  that  a 
possibility  exists  for  analyses  and  data  generation  efforts 
to  be  product-oriented,  rather  than  goal -oriented.  By  this 
it  is  meant  that  many  analyses  may  be  undertaken  for  the 
sole  purpose  of  providing  documentation  for  higher-level 
(e.g.,  DSARC  or  ASARC)  decision-making,  rather  than 
directed  toward  ensuring  that  the  most  effective  life  cycle 
cost-efficient  personnel /materiel  system  possible  is 
produced.  No  evidence  of  a  structured,  results-oriented 
process  for  analyzing  and  defining  the  potential  MPT 
impacts  of  system  concepts  is  present  in  any  of  the 
documents  reviewed  in  this  work.  Several  studies  have 
defined  the  need  for  such  a  process,  however  (e.g.,  Rhode, 
Skinner,  Mullin,  Friedman,  Franco,  and  Carroll,  1980). 

An  approach  to  identifying  how  such  a  process  should  be 
structured  and  the  procedures  which  might  be  adopted  in  the 
process  might  begin  by  working  backward  from  the  "critical 
decisions"  defined  earlier  in  this  report.  The  information 
required  to  make  each  of  those  decisions  would  be  defined, 
in  terms  of  specific  data  items,  and  the  processes  that 
should  be  performed  to  derive  the  data  would  define  a 
"criterion"  against  which  to  evaluate  the  data  generated 


and  procedures  utilized  in  decision-making  in  past  or 
current  acquisitions.  Several  representative  system 
acquisitions  would  then  be  selected  for  study,  to  determine 
what  data  actually  are  generated  by  analyses  and  studies 
during  concept  exploration  efforts,  and  how  these  data  feed 
into  the  decision-making  process.  Emphasis  in  this  study 
of  the  representative  acquisitions  would  be  on  identifying 
cases  in  which  needed  data  are  not  generated  or  where  the 
quality  and  quantity  of  the  data  are  not  sufficient  to 
support  critical  MPT  decisions,  and  determining  the  reasons 
why  such  data  are  not  generated.  The  study  would  further 
attempt  to  identify  the  degree  of  structure  and  coordina¬ 
tion  that  typically  exists  in  MPT-oriented  studies  and 
analyses  during  system  concept  exploration  in  the  repre¬ 
sentative  acquisition  efforts,  and  where  additional 
structure  and  information  would  facilitate  efficient 
analyses  and  decisions.  It  is  understood  that  this  will 
not  be  an  easy  process:  the  audit  trail  for  decisions 
during  early  phases  of  system  acquisition  is  often  obscure 
(especially  with  systems  which  are  near  introduction  into 
the  inventory,  or  already  fielded),  personnel  involved  in 
the  decision  and  analysis  processes  may  have  long  since 
moved  on  to  other  responsiblities,  etc.  However,  in  order 
to  influence  and  rationalize  the  system  concept  exploration 
process  with  respect  to  MPT  considerations,  it  must  first 
be  known  what  processes  are  used  and  what  products  are 


produced  by  the  tradeoffs,  analyses  and  studies  during  this 
phase,  and  how  useful  and  utilized  the  outputs  of  the 
processes  are.  If,  as  it  is  suspected,  the  processes  and 
products  are  idiosyncratic  to  Individual  system  develop¬ 
ments,  the  introduction  of  defined  process  and  structure  to 
the  task  of  defining  and  studying  MPT  Impacts  and  trading 
off  MPT  impacts  and  materiel  system  characteristics  will 
prove  of  value,  if  only  as  a  framework. 

After  the  representative  system  acquisitions  have  been 
examined  individually,  the  results  of  the  process  studies 
would  be  combined  to  form  an  overall  critical -incident- 
based  picture  of  the  errors,  omissions,  and  discontinuities 
that  were  identified  in  the  process  of  studying  and 
analyzing  the  MPT  factors  of  contemplated  systems,  during 
concept  exploration  and  development.  This  would  include 
consideration  of  reasons  why  critical  data  were  not 
generated,  were  not  sufficient  for  decision-making,  or  were 
not  used  (and  combinations  of  these).  This  critical 
incident  analysis  would  be  used  to  define  the  evolutions 
and  processes  in  system  concept  exploration  where  addi¬ 
tional  structure  is  needed  or  where  processes  are  inade¬ 
quate  (or  do  not  exist)  for  generating  needed  data.  Each 
of  the  identified  needs  would  then  be  explored  in  detail  to 
determine  whether  techniques  and  procedures  presently  exist 
which  could  be  applied  during  the  concept  exploration 
process  to  improve  the  quality  and  impact  of  data  on  system 
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MPT  issues.  Where  such  techniques  exist,  the  specific 
points  where  the  techniques  and/or  procedures  would  be 
introduced  would  be  identified  and  approaches  for  their 
introduction  specified.  In  addition,  an  overall  data  and 
decisions  flow  model  for  the  generation  and  application  of 
MPT  data  during  concept  exploration,  based  on  the  initial 
step  of  the  study,  but  much  more  refined  to  include  all  the 
processes,  products,  and  decisions  identified  in  the 
critical  incident  study,  would  be  prepared.  This  model 
would  serve  as  a  framework  for  evolving  the  structure  of 
early  stages  of  the  system  acquisition  process  to  ensure 
that  appropriate,  timely  and  complete  consideration  and 
study  of  MPT  issues  is  made  during  critical  decision¬ 
making  and  tradeoffs,  based  on  the  most  accurate  and 
complete  data  which  can  be  made  available. 

2.  Perhaps  the  most  important  and  valuable  future  development 
which  has  been  identified  in  this  effort  is  the  need  for  a 
"roadmap"  to  guide  designers  in  the  use  of  existing  tech¬ 
niques,  procedures,  and  data  to  minimize  the  MPT  require¬ 
ments  of  systems  under  design.  A  great  many  highly  useful 
tools  and  techniques  and  extensive  data  have  been  developed 
by  the  human  factors  and  training  cormiunities  which  can  be 
directly  applied  to  evaluating  design  characteristics  and 
decisions  for  gross  or  detailed  impact  upon  manpower  and 
training  requirements.  These  include  guidelines  for 
function  allocation  to  humans  versus  hardware,  task  and 


skill  analylsls  techniques,  man/machine  interface  design 
principles  and  evaluation  tools,  training  requirements 
analysis  procedures,  maintainability  design  principles,  and 
many  others.  All  of  these  tools  and  techniques  are 
potentially  usable  in  the  hardware  design  process  to 
evaluate  and  control  the  impacts  of  materiel  system  design 
characteristics  upon  requirements  for  personnel  and 
training,  if  used  in  an  appropriate  and  timely  manner. 

As  mentioned  in  the  Introduction  to  this  report,  one 
primary  reason  why  these  techniques  and  data  are  not  used 
by  engineering  designers  is  that  the  designer  does  not 
understand  the  purpose  and  application  of  the  tools  and 
techniques  in  the  design  process.  It  is  clear  that  the 
designer  will  need  to  be  able  to  apply  techniques  and  data 
to  define  the  MPT  impacts  of  design  decisions  and  thus 
intelligently  trade  off  design  alternatives,  in  order  to  be 
able  to  meet  all  of  the  constraints  upon  the  resulting 
design,  from  both  the  MPT  viewpoint  and  that  of  materiel 
system  performance  objectives.  Yet  the  designer  is 
ignorant  of  the  usefulness  and  utilization  of  the  existing 
tools  to  help  make  these  determinations.  The  designer  thus 
needs  to  be  provided  with  explicit  guidance  on  the  nature, 
scope,  and  applicability  of  the  available  tools,  tech¬ 
niques,  and  data. 

In  order  to  create  a  "designer's  roadmap,"  it  will  be 
necessary  to  compile  all  of  the  existing  techniques  and 


bodies  of  data  dealing  with  human  performance  capabilities 
and  limitations  and  the  relationships  of  these  characteris¬ 
tics  to  hardware  design  factors,  training  requirements, 
etc.  The  available  techniques  and  the  materiel  system 
design  process  will  then  have  to  be  evaluated  jointly,  to 
determine  where  and  to  what  extent  in  the  design  process 
each  technique  and  data  should  be  applied  (many  of  the 
techniques  can  be  applied  at  the  front  end  of  the  design 
process  to  generate  design  parameters  and  constraints 
directly  addressing  hardware  design  factors).  From  this 
study,  a  handbook  of  techniques  and  data  which  are  useful 
in  evaluating  MPT  impacts  of  design  alternatives  and 
providing  guidance  to  the  designer  can  be  derived.  The 
handbook  must  include  guidance  for  the  designer  as  to  the 
limitations  of  each  technique  and  data  set,  how  each  can  be 
applied  during  the  design  process,  and  how  the  information 
that  can  be  derived  from  applying  the  procedures,  data, 
etc.  can  help  the  designer  to  meet  MPT  constraints  on  the 
characteristics  of  his  system.  The  handbook  should  also 
include  explicit  guidance  as  to  how  procedures  are  to  be 
applied,  what  data  are  appropriate  for  what  kinds  of 
decisions  or  tradeoffs,  and  most  especially  acknowledge  the 
limitations  of  the  techniques  and  data  provided.  The 
handbook  should  be  a  practical  document  for  use  by  the 
working  design  engineer  and  engineering  manager,  which 
stresses  the  intimate  relationships  between  hardware  design 


factors  on  the  one  hand  and  manpower  and  human  performance 
characteristics  on  the  other.  Several  different  levels  of 
presentation  may  be  appropriate  for  inclusion  in  the 
designer's  handbook,  including  detailed  data  summaries  (and 
how  and  when  to  to  apply  the  data),  procedures  for 
performing  various  kinds  of  analyses  (and  when  and  why  the 
analyses  are  appropriate),  and  general  principles  for 
optimizing  human  factors  impacts  of  design. 

The  two  needed  developments  discussed  above  address  critical 
future  developments  in  the  development  of  a  means  to  control  and 
constrain  the  MPT  requirements  of  evolving  materiel  systems.  On  the 
government  side  of  the  system  acquisition  process,  it  has  been  proposed 
that  the  procedures  and  techniques  for  addressing  MPT  issues  in  system 
concept  development  be  explored  in  depth  to  determine  how  to  make  those 
procedures  more  complete  and  responsive  to  the  critical  needs  of 
decision  makers  who  determine  what  factors  will  be  traded  off  (and  in 
what  ways)  to  attain  maximum  materiel  system  performance  with  an 
optimal  minimum  of  requirements  for  manpower  and  training.  On  the 
designer's  side  of  the  picture,  a  need  clearly  exists  to  make  available 
and  usable  to  the  designer  the  data  and  techniques  which  will  assist 
the  designer  in  designing  capable  systems  with  minimum  requirements  for 
trained  people  to  operate  and  maintain  the  systems.  It  is  recommended 
that  vigorous  efforts  along  both  lines  of  progress  be  pursued  beginning 
in  the  near  future,  to  take  the  next  step  in  creating  a  "common 
language"  which  will  foster  efficient  and  effective  use  of  resources  to 
minimize  ultimate  MPT  impacts  of  future  Army  systems. 
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LISTING  OF  PROCESSES  AND  DECISIONS  DURING 
MATERIEL  SYSTEM  ACQUISITION  WHICH  IMPACT 
MANPOWER,  PERSONNEL,  AND  TRAINING  REQUIRMENTS 


Mission  Area  Analysis  Phase  (LCSMM  Phase  0) 

Subsystem  Analyses  (After  MENS,  before  LOA)  -  coordinated  throuqh 

JUG  ( TRADOC/ DA&CDM) . 

-  Develop  subsystem  concepts  iteratively:  top-level  design/MPT 
tradeoffs  (not  explicit  or  empirically  based). 

-  Perform  concept  front-end  analysis  (TRADOC  Proponent  School: 
training  developments). 

.  Analyze  and  identify  functions  to  be  performed  in  system 
operation  (mission  profile). 

.  Identify  comparability  of  existing  systems  to 
proposed/needed  system  capability  to  determine  if 
existing  systems  can  be  used  for  analyses/projections 
(operational  comparability/technological  comparability). 

.  Contrast  required  operational  functions  to  data  from 
comparable  systems  (occupational  surveys)  to  produce  task 
listings  [this  is  the  first  point  in  the  process  where 
task  data  is  generated;  can  condition  later  decisions]. 

.  From  task  listings  and  occupational  survey  data,  identify 
critical  tasks  and  estimate  priority  of  task  training  for 
critical  tasks;  perform  gross  task  analyses. 

.  OUTPUT:  training  planning  document  (portions). 

-  Perform  logistic  support  planning  (TRADOC  Proponent 
School /DARCOM). 

.  Perform  HFE  analysis  of  system  concept  to  identify 
probable  operation  and  maintenance  issues  and  areas  of 
concern  and  emphasis  (mission  profile). 

.  Acquire  technical  data  on  "comparable"  (technological  or 
operational -use)  systems  to  be  used  for  logistic  and 
training  requirements  analysis. 
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.  Develop  training  support  concept  based  on  "comparable" 
system  data  (training  facilities  estimates,  initial 
training  device  requirements). 

.  Create  initial  manpower/personnel  concept  (numbers  of 
people,  probable  skill  levels,  comparable  MOS's)  -  based 
on  "comparable"  system  data. 

.  Create  initial  maintenance  concept  (levels  of 
maintenance,  possible  distribution  of  maintenance 
functions  to  levels)  based  on  "comparable  system  data 
HFE  analyses. 

Develop  individual/collective  training  concepts  (TRADOC 
Proponent  School /DTD). 

.  Identify  preliminary  Individual/collective  training  needs 
based  upon  available  data  for  "comparable"  systems 
(iterative  developments). 

*  Tasks  to  be  trained  (based  on  occupational- 
survey-based  "task  analysis"). 

*  Collective  versus  individual  tasks. 

*  Maintenance  versus  operational  tasks. 

*  Training  modes  and  distribution  of  tasks  across 
modes. 

*  Training  device  and  documentation  requirement 
estimates. 

*  Evaluation  requirements  (SQT,  ARTEP). 

.  Develop  initial  estimates  of  training  resource 

requirements  (based  on  "comparable"  system  data,  studies, 
estimates). 

.  Develop  initial  training  concept. 

.  Develop  initial  training  strategy. 

.  Results  in  Outline  Individual  and  Collective  Training 
Plan  (OICTP)  -  inputs  to  initial  CTEA  and  Best  Technical 
Approach  (BTA)  selection. 


All  subsystem  analysis  outputs  (training  planning  document, 
logistic  planning  document,  01CTP)  Input  into  LQA  paragraph  V 
(manpower). 


.  Training  development  mllestones/schedule  developed  for 
LOA. 


After  LOA  approval,  PM  office  established,  TSM  appointed  within  TRADOC, 
Special  Task  Force  (STF)/Special  Study  Group  (SSG)  appointed  by  CG 
TRADOC  to  pursue  further  concept  development  studies  In  Phase  I. 

STF/SSG  includes  TSM,  PM  representative,  DARCOM  CD  representative, 
logistics  (DCSLOG)  representation. 


Concept  Exploration  Phase  (LCSMM  Phase  1) 

.  Identify  system  alternatives  to  meet  Identified  need. 

System  Design  Concept  Exploration 

-  Generation  of  organizational  and  operational  concepts  (TRADOC 
Proponent  School  -  DCD). 

.  Number  of  systems  required  to  fulfill  operational  need 
(est.  from  MENS,  mission  profile). 

.  How  systems  will  be  employed  In  combat  to  meet  need. 

.  Unit  structure  to  operate  and  support  systems  (similar 
systems,  missions). 

.  Personnel  characteristics  to  operate  and  maintain  systems 
(earlier  HFE  and  manpower /maintenance  concepts,  special 
adjunct  studies  -  often  contract). 

.  All  of  the  above  are  traded  off  -  conceptually  -  during 
design  Iterations  and  concept  development. 

.  Results  of  organizational  and  operational  concept 
definition  are  primary  feeder  data  for  TQQPRI,  BOIP  I, 
and  ILS  plans. 

-  Generation  of  force  level  guidance  (ODCSOPS,  Staff  studies). 

.  Analyze  Impact  on  force  structure  of  proposed  system 
concepts  (using  mission  profile  assumptions  and  MENS 
descriptions,  organlzatl on/operational  concepts 
statements). 

.  Tradeoffs  of  Impact  on  force  structure  to  accomplish 
mission;  feeds  back  Into  organizational /operational 
concepts.  Introducing  constraints  on  force  level  Impact 
( recommendations ) . 

Material  Concept  Investigation  (PM  office,  TSM,  Proponent 

School >Combat  Developments) 

-  Evaluation  of  state-of-art  technology  to  address  mission 
need. 


-  Exploration  of  manpower  Impacts  of  technologies. 

.  Identification  of  special  ski 11 /know! edge  requirements  of 
technological  alternatives  (strong  possible  Impacts  on 
selection  and  training). 


-  Evaluation  of  training  system  capability  to  support  technology 
and  personnel  performance  requirements  -  includes  CTEA  of 
alternative  concepts. 

-  At  this  point,  a  set  of  system  concepts  which  may  fulfill  the 
agreed-on  mission  need  has  been  defined.  The  alternative 
concepts  are  next  evaluated  comparatively,  in  the  preparation 
of  the: 

Concept  Formulation  Package  (CFP)  (Coordinated  by  STF/SSG) 

-  Trade-Off  Determination  (DARCOM  PM  Office) . 

.  Explicit  identification  of  technical  approaches 
considered  in  material  concept  investigation. 

.  Estimation  of  required  RDT&E  to  develop  each  approach. 

.  Define  alternatives  to  be  examined. 

.  Identify  areas  where  tradeoffs  are  to  be  performed 
(technological  risk,  cost,  schedules,  system 
capabil ities,  logistic  support,  MPT)  -  explicit  tradeoff 
issues  defined.  Criteria  may  be  established. 

-  Trade-off  Analysis  (TOA)  (DARCOM  PM/TRADOC  proponents/ 
contractor  support) . 

.  Gather  data  (estimtes)  on  which  to  base  tradeoffs 
("comparable"  systems,  concept  estimates,  desired 
baselines,  etc.). 

.  Conduct  trade-off  studies  between  approaches  (MPT,  ILS, 
HFE  issues  should  be  considered  and  weighted  in 
trade  offs.  Criteria  established  in  TOD  must  be 
addressed . 

-  Best  Technical  Approach  (BTA)  (TRADOC/DARCOM:  STF/SSG) 

.  Selection  of  the  favored  technical  approach  for  further 
development  and  inclusion  as  preferred  approach  in  CFP. 

.  Considers  cost,  MPT,  ILS  factors  assessed  in  TOA. 

-  Cost  and  Operational  Effectiveness  Analysis  (COEA)  (Proponent 


From  TOD,  TOA,  BTA,  CTEA,  and  input  data  (system  and  material 
concepts).  Concept  Formulation  Package  (CFP)  is  prepared, 
which  describes  system  concepts  selected  for  development  and 
their  ramifications  in  terms  of  schedule,  cost,  effectiveness, 
manpower,  training,  and  logistic  support. 

The  CFP  feeds  directly  into  the  draft  Decision  Coordinating 
Paper  (DCP),  which  is  modified  by  several  development  and 
planning  updates  while  in  draft  form: 

Training  Development  Requirements  Update  (TRADOC  Proponent 
School  and  TSM  -  Updates  OICTP. 

.  Reassess  and  reformulate  if  necessary: 

°  List  of  critical/high  training  risk  tasks  (input 
from  concept  FEA  as  updated  by  CFP  decisions). 

0  Training  device  requirements  (updated  estimate  based 
on  refinements  and  selection  during  CFP  process). 

°  Identify  SPA  requirements  at  relatively  global  level 
(input  from  concept  FEA,  trade-offs  and  constraints 
during  DCP  anlaysis). 

Training  Management/Admini strati on  Planning  Update  (TSM) . 

.  Revise  OICTP  requirements,  refine  on  basis  of  better 
focus  on  system  gained  during  CFP  analyses. 

Another,  parallel,  stage  in  development  of  the  draft  DCP  is 
preparation  of  a  Program  Management  Plan  (PMP),  vrfiich 
describes  proposed  acquisiton  stategy  and  procedures.  The  PMP 
(prepared  by  the  DARCOM  PM  office,  with  coordination  with  TSM, 
Proponent  School,  ODCSLOG,  and  OTEA)  is  a  critical  point  for 
introducing  or  reinforcing  constraints  which  may  impact  MPT, 
since  it  contains  the  following: 

.  Coordinated  Test  Program  Plans. 

°  Training  test  plan  (training  concepts, 

effectiveness,  devices,  etc.),  based  on  training 
concepts  document  prepared  in  Phase  0. 

°  First  cut  at  training  test  plans  for  developmental 
and  operational  testing. 


Updated  OICTP,  including  plans  for  further  manpower 
and  personnel  developments. 
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°  Logistic  support  plan,  including  RAH  objectives  and 
ILS  development  plan. 


After  AsARC  review,  the  OCP  is  revised  to  take  into  account 
recommendtions  by  AsARC.  To  support  final  DCP  I,  an  Integrated  Program 
Summary  (IPS)  is  prepared  by  ODCS  (research,  development  and 
acquisition),  which  includes  MPT  support  data  as  follows: 

.  ILS  development  plan. 

.  R&M  design  goals. 

.  Manpower  requirements: 

°  System  activity  level  (number  and  utilization  of 
systems) . 

°  Sensitivity  of  manpower  to  alternative  system 
concepts  (from  TOD,  TOA) . 

°  Innovative  maintainability  and  productivity  concepts 
to  be  deluded  in  development  plans. 

.  Training  Requirements. 

°  Implications  of  alternative  system  concepts  for 
training. 


Once  DSARC  aproval  to  enter  demonstration  and  validation  phase  has  been 
obtained,  PMP  is  updated  along  with  preparation  of  the  contract  RFP  for 
the  demonstration  and  validation  phase,  and  DT/OT  I  test  criteria  and 
pi ans . 
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Demonstration  and  Validation  Phase  (LCSMM  Phase  II) 


.  Develop  technological  approaches/systems  and  select 
system  that  best  fulfills  need  as  described  in  LOA. 

-  PMP  Update  and  RFP/SOW  Input:  (DARCCM  PM/TRADOC  TSM/Proponent 
School  ) . 

.  Personnel /training  requirements  and  specifications  to  be 
following  by  contractor. 

.  Statement  of  plans/ objectives  for  individual  and 

collective  training  and  evaluation  (from  OICTP;  evaluated 
at  DT/OT  I) . 

.  Plan  and  objectives  for  development  of  training  materials 
to  support  operation  and  maintenance  test/eval uation  at 
DT/OT  I  (contractor  requirements). 

.  RAM  requirements  to  be  met  by  contractor  systems  to  be 
devel oped . 

-  The  above  arc  integrated  into  the  SOW  and  should  be  utilized 
as  proposal  evaluation  criteria.  At  this  stage,  MPT 
requirements  should  be  stated  in  design- to-constraints  terms. 

-  Contractor:  Interprets  requirements  and  objectives,  prepares 
proposal  . 

.  After  award . 

.  Conducts  LSA  in  accordance  with  contract  requirements 
(ideally).  Typically,  LSA/LSAR  is  given  less  attention 
then  desirable.  Delivery  of  LSA  data  during 
demonstration  and  validation  contracts  should  be 
required,  to:  (A)  verify  that  analyses  to  support 
training  and  logistics  developments  have  in  fact  occurred 
as  specified;  (B)  support  development  of  TQQPRI  and  BOIP 
after  DT/OT  I  and  selection  of  single  system  for  FSED). 

.  Conducts  training  FEA  and  develops  training  materials  to 
support  training  at  DT/OT  I. 

.  Verifies  OICTP  estimates  with  actual  developmental  data. 

-  Development  of  DT/OT  I  Coordinated  Test  Plans  (DARCOM/TECOM/ 
TRADOC/OTEAr 

.  Criteria  for  training  materials  and  training  objectives 
satisfaction. 


.  Supportability  criteria  (reliability,  maintainability, 
operability). 

.  Criteria  for  assessing  design  problems  that  impact  RAM. 
.  Criteria  for  manpower  assessment. 

.  Criteria  for  assessing  training  concept/feasibility: 

*  Training  device  prototypes  (performance,  adequacy, 
comprehensiveness) . 

*  Documentation  (SPA,  SM,  TM). 

*  Human  performance  standards. 

*  Supportability  of  planned  training  developments 
(PMP) . 

.  Criteria  for  ILS/Logistics  issues: 

*  RAM. 

*  Manpower/personnel  requirements. 

°  Maintenance  related  design/material  problems. 


Tffter  DT/OT  I,  Logistics  Support  requirements  and  Training/ 
TOR  requirements  are  updated  to  reflect  data  and  results  from 
DT/OT  test  and  evaluation,  for  the  system(s)  selected  for 
full-scale  engineering  development.  These  updates  and 


analyses  are  reflected  inthe  Required  Operational  Capability 
(ROC)  document. 


.  Re-evaluate  adequacy  of  RAM  in  light  of  objectives  and 
achievements  in  DT/OT  I.  Modify  requirements  if  too 
lenient  or  cannot  be  met. 


.  Examine  adequacy  of  LSAR  produced  during  contractor 
efforts  for  ability  to  support  QQPRI,  BOIP,  MOS 
determinations  at  tentative/first-cut  stage. 


Refine  Training/Training  Device  Requirements  and  Prepare 
Individual/Collective  Traininq  Plan  (ICTP)  (TRAOOC  Proponent 
5cFo6T7T5M)" -  - - 


Evaluate  TOR  adequacy  and  update  requirements  as 
necessary. 


.  Assess  value  of  training  concept  against  DT/OT  results 
and  revise/ update. 

.  Assess  documentation  performance  (SPA,  SM,  TM,  TEC) 
during  DT/OT  -  modify/update  plans  and  requirements, 
etc . 

.  Identify  probable  training  pipeline  and  quotas. 

.  Assess  new  equipment  training  requirements  and  include  in 
overall  training  plan. 

Prepare  tentative  QQPRI  (TQQPRI)  from  DT/OT  contractor  LSA 
data,  OT  experience,  and  operational/organizational  concepts 
(DARCOM  PM/MRSA/TRADOC  Proponent  School). 

.  Crew/operator  estimates  (with  MOS  estimates) . 

.  AMMH  estimates  (by  MOS)  for  each  level  of  maintenance. 

.  Duty  positions  (with  task  listings)  for  maintenance  and 
operation. 

.  Lists  of  skills,  knowledge,  qualifications  for  personnel 
to  operate,  maintain  system  (include  physical  and  mental 
standards) . 

Prepare  Basis  of  Issue  Plan  (BOIP)  I  (TRADOC  Proponent  School) 
using  tQQPRI,  0&0  concept,  BOIP  feeder  data  (describes  Prime 
Item  and  Support  Equipment). 

.  Define  tentative  initial  unit  structure  to  support, 
operate  system. 

.  Contains  unit  manpower  estimates. 

.  Also  contains  equipment  distribution  requirements. 

.  Feeds  into  MILPERCEN  MOS  determinations. 

Prepare ^Required  Operational  Capability  (ROC)  Document 

.  Describes  system  selected  from  those  developed  in  Phase  I 
to  be  further  devleoped  In  full-scale  development  (Phase 
III). 

.  Includes  updated  logistic  support  plan  (ILS  Plan). 

.  .  Presents  revised  and  updated  training  and  training 
support  estiamtes  for  system  (ICTP). 
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Updated  CTEA  and  COEA  performed  for  system  to  be 
developed. 


In  support  of  the  (brief)  ROC,  an  Updated  Program  Management 
Plan  (PM>)  is  prepared  under  the  direction  of  a  reconvened  or 
reappointed  STF/SSG.  DARCOM  PM  is  prime  mover  for  update  of 
PMP  for  full-scale  development.  The  update  PMP  contains 
several.  MPT— related  segments,  based  on  post— DT/OT  I 
analyses. 

.  Initial  BOIP  I— personnel ,  MOS,  and  tentative  unit 
structure  for  system  and  support  systems  for  using 
units. 

.  System  development  plans,  including  RAM  objectives  and 
criteria  for  full-scale  development  (PM  Office). 

.  Coordinated  test  plan  for  OT/OT  II  and  intermediate 
testing. 

°  Training  test  plan  (TSM) . 

0  DT/OT  II  test  plans  (not  yet  detailed  criteria). 

.  Personnel  and  training  requirements  developments. 

°  New  skill,  MOS  requirements  from  TQQPRI  (TSM, 
MILPERCEN) . 

°  New  Equipment  Training  (NET)  plans. 

°  The  ICTP  and  plans  for  its  implementation  during 
testing  (TSM,  Proponent  School). 

0  Training  device  requirements  update. 

°  Training  facilities  estimates  and  plans. 

.  Logistic  support  plans  (PM). 

°  Identification  of  critical  supportabil ity  issues 
(identified  through  DT/OT  I  testing  and  HFE 
evaluation)  and  plans  for  dealing  with  issues. 

°  RAM  objectives/criteria  for  FSED  system(s). 

0  ILS  plan  and  objectives. 
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Full-Scale  Engineering  Development  (LSCMM  Phase  III) 


-  Preparation  of  criteria  for  RFP/SOW  Source  Selection  (PM 
Coordination). 

.  For  the  FSEO/Prototype  contract  SOW,  several  "constraint 
areas  are  critical  to  MPT  impacts  of  both  the  prototype 
and  the  potential  follow-on  operational  systems.  These 
include: 

°  HFE  criteria  which  prototypes  must  meet. 

°  LSA/LSAR  data  requirements  and  schedules. 

°  Validation/verification  of  training  needs,  tasks, 
skills  and  knowledge. 

°  Documentation  criteria. 

°  Validation  of  training  device  requirements. 

0  Etc. 

-  Coordinated  Test  Plan  Inputs  for  DT/OT  II  (PM) . 

.  Test  Objectives,  Plans  for  DT  II  (tests:  TECOM/AMSAA) . 

°  Training  materials  validation  plan  and  criteria. 

°  RAM  criteria. 

°  Maintenance  task  validation  and  performance 
criteria. 

°  Manpower  and  skill  requirements  criteria. 

0  Documentation  criteria  (TM,  FM,  SPA). 

0  Training  device  performance  and  supportabil ity 
requirements  criteria. 

°  NOTE:  These  criteria  should  be  closely  related  or 
identical  to  specifications/constraints  in  FSED  RFP 
to  ensure  communication  and  accountabil ity/ audit 
trail . 

.  Test  Objectives.  Plans  for  OT  II  (Tests:  OTEA) . 

0  Documentation  (TM)  validation  plans  and  criteria. 
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Operator  and  maintainer  training  adequacy/ 
performance  criteria. 

°  Personnel  requirements  criteria . 

0  RAM  criteria. 

0  ILS  criteria. 

0  Training  planning  (ICTP)  validation  plans  and 
criteria . 

°  NOTE:  Those  criteria  should  also  be  closely  tied  to 
RFP  requirements/constraints. 

Parallel  Development  in  Support  of  OT/DT  II:  (PM 
Coordination). 

.  Contract  development  of  SPA,  TMs,  etc.  for  FSED  system 
(may  be  prime  contractor  or  separate  contract) . 

.  Training  device  development  (may  be  prime  or  separate 
contract) . 

.  In  both  these  areas,  decisions  regarding  specifications, 
front-end  analysis  requirements  and  cross- feed  with  FSED 
prime  contractor  are  critical  to  the  development  of 
appropriate,  complete,  usable,  and  timely  support  items 
for  evaluation. 


Following  OT/DT  II,  logistic  support  and  training  planning  are  again 
updated,  this  time  on  the  basis  of  data  from  the  FSED  effort  and  DT/OT 
II.  This  is  a  critical  point  in  verification  of  whether  design  and 
development  constraints  that  impact  MPT  issues  have  been  understood  and 
implemented.  During  these  updates,  decisions  are  made  about  the 
adequacy  of  developments  and  resolutions  of  issues  which  will  affect 
manpower  requirements,  training,  and  system/ subsystem  supportabil ity . 

-  Logistic  Support  Planning  Update  (ODCSLOG/PM/MRSA) . 

Validation  of  LSA  Data  via  teardown  of  prototype 
equi pment .  Determines  whether  maintenance  task/skill 
requirements  have  been  identified,  and  identifies 
operator/maintainer-system  Interface  Issues  yet  to  be 
resolved/ addressed . 

Determine  Adequacy  of  Projected  Maintenance  Manpower 
Requirements  (AMH)  from  OT  II  test  results  to  determine 
1 t  personnel  requirements  projections  are  accurate  and 
adequate . 


-  Training  Planning  Update  (TSM/Proponent  School ) . 

.  Validate  Previous  Personnel  Requirements  Raised  on 
Logistic  (LSA)  Data  -  Determine  whether  operator, 
maintained  projections  accurate  in  light  of  obtained 
OT/OT  II  results;  modify  plans  if  projections 
inaccurate. 

.  Update  Training  Plans  (SPA,  FM,  TM,  etc.)  and  develop 
preparation/impl ementation  plans  to  support  system  IOC. 

-  Prepare  Updated  QQPRI  (PM  cognizance)  and  BOIP. 

.  Acquire  FSED  LSAR  data  and  update  operator,  maintenance 
skill,  task,  MOS,  and  force  structure  requirements  data 

-  Prepare  Final  MOS  Decisions  and  Determinations  (MILPERCEN). 

.  Based  on  updated  QQPRI. 


Revised  training  ana  logistics  plans,  updated  QQPRI  and  MOS  decisions 
are  documented  in  an  updated  Program  Management  Plan  (PMP)  which 
contains  (among  other  things): 

0  Production  RAM  requirements  (using  military 
personnel ) . 

°  Identification  of  unresolved  logistic  support 
issues. 

°  Revised  BOIP. 

0  Revised  personnel  and  training  plans  and 
requirements . 

°  Updated  QQPRI  and  MOS  decisions. 

0  Updated  resident  and  unit  training  plans  (ICTP) . 

°  DT/OT  III  test  plans. 


.  As  at  earlier  stages,  the  PMP  feeds  into  the  DCP.  Upon 
ASARC/DSARC  approval,  low-rate  production  can  begin. 


APPENDIX  C 


LIST  OF  ACRONYMS  AND 
ABBREVIATIONS  USED  IN  THIS  REPORT 

Annual  Maintenance  Manhours 

Army  Materiel  Systems  Analysis  Activity 

Army  Training  and  Evaluation  Process  (Plan) 

Army  Systems  Acquisition  Review  Council 
Basis  of  Issue  Plan 
Best  Technical  Approach 
Combat  Developments  (Developer[s] ) 

Concept  Formulation  Package 

Cost  and  Operational  Effectiveness  Analysis 

Cost  and  Training  Effectiveness  Analysis 

U.S.  Army  Material  Development  and  Readiness  Command 

Department  of  Combat  Developments 

Decision  Coordinating  Paper 

Deputy  Chief  of  Staff  for  Logistics 

Defense  Systems  Acquisition  Review  Council 

Development  Test(ing) 

Department  of  Training  Developments 

Front-End  Analysis 

Full-Scale  Engineering  Development 

Human  Factors  Engineering 

Individual  and  Collective  Training  Plan 

Integrated  Logistic  Support 

Initial  Operational  Capability 

Integrated  Program  Summary 

Instructional  Systems  Development 

Joint  Working  Group 

Life  Cycle  System  Management  Model 

Letter  of  Agreement 

Logistic  Support  Analysis  Record 


TECOM 


TQQPRI 


TRAOOC 
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MENS  Mission  Element  Needs  Statement 

MILPERCEN  Military  Personnel  Center 
MOS  Military  Occupational  Specialty 

MPT  Manpower,  Personnel,  and  Training 

MRSA  Material  Readiness  Support  Activity 

NET  New  Equipment  Training 

ODCSOPS  Office  of  the  Deputy  Chief  of  Staff  for  Operations 
OICTP  Outline  Individual  and  Collective  Training  Plan 

O&O  Organizational  and  Operational  (Concept) 

OT  Operational  Test(ing) 

OTEA  Operational  Test  and  Evaluation  Agency 

PFC  Private  First  Class 

PM  Program  Manager 

PMP  Program  Management  Plan 

QQPRI  Qualitative  and  Quantitative  Personnel  Requirements  Information 

RAM  Reliability,  Availability,  and  Maintainability  (Analysis) 

RDT&E  Research,  Development,  Test,  and  Evaluation 

RFP  Request  for  Proposal 

ROC  Required  Operational  Capability 

SAP  Systems  Acquisition  Process 

SOW  Statement  of  Work 

SM  Soldier's  Manual 

SPA  Skill  Performance  Aids 

SQT  Skill  Qualification  Test 

SSG  Special  Study  Group 

STF  Special  Task  Force 

TDR  Training  Device(s)  Requirement 

TEC  Training  Extension  Course(s) 

TECOM  Test  and  Evaluation  Command 

TM  Technical  Manual 

TOA  Tradeoff  Analysis 

TOD  Tradeoff  Determination 

TOE  Tables  of  Organization  and  Equipment 

TQQPRI  Tentative  Qualitative  and  Quantitative  Personnel 

Requirements  Information 

TRAOOC  U.S.  Army  Training  and  Doctrine  Command 

TSM  TRADOC  System  Manager 
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